What if people could use the same business application in the place that suits them?

One person might open a familiar standalone web app. Another might ask an assistant to find something and work with the application right inside the conversation. A third might use a company’s Microsoft Copilot experience. And, where the client supports it, the person might speak instead of type.

This is the direction I am exploring with MCP Apps and my IBM i Sales Workspace. It is more than adding a chatbot to an existing application: it changes how we can think about the relationship between business capabilities, user interfaces, and the host applications people already use.

From one application per platform to one capability, many experiences

Traditionally, a business system’s interface is tightly coupled to where it runs. A browser gets a web app; a collaboration platform gets its own component; a mobile client may need another implementation. Each can end up duplicating UI and integration logic, even when all of them are trying to work with the same business data.

The Model Context Protocol (MCP) provides a standard way for an MCP client to discover and call tools exposed by an MCP server. MCP Apps build on that model by allowing a server to offer an interactive user interface associated with its tools. A compatible host can render that UI and connect it to the server through the MCP Apps bridge.

The important shift is that an application can be more than a page that owns its API calls. It can expose:

• Business capabilities as typed, discoverable MCP tools.
• An interactive interface as an MCP App resource that a compatible host can display.
• A standalone experience that uses the same capabilities and can render the same workspace outside a conversation.

That creates a useful separation: the business application provides its functionality, while the user can choose a supported place to interact with it. The host still matters, though. MCP Apps do not mean every UI bundle runs unchanged in every assistant or platform. A host must support the relevant MCP Apps behavior, and integrations may need host-specific work.

The IBM i Sales Workspace: one service, three ways in

My IBM i sample makes the idea concrete. It connects a React sales workspace to IBM i Db2 through a Node.js MCP server and Mapepire. The server registers the business tools and serves the workspace as an MCP App resource. The interface is built with React and Fluent UI.

The current solution has three entry points:

1. Standalone web application. A Vite/React web host connects to the MCP endpoint through a server-side proxy and displays the workspace with the official AppBridge. It is a normal web experience; it does not need an AI model or an API key.
2. MCP Apps host. A compatible MCP client can discover the workspace resource and render it alongside the conversation and tools. The exact experience depends on that client’s MCP Apps support and host policies.
3. Microsoft Copilot experience. An SPFx Copilot component provides a Copilot-facing entry point, routes typed requests to the existing sales tools, and reuses the workspace. This is a platform-specific integration—not a claim that every Copilot surface automatically supports MCP Apps resources. The current SharePoint Copilot component is preview functionality and should be validated in a development tenant.

The shared path looks like this:

Standalone web host ───────┐
MCP Apps-compatible client ─┼── MCP tools + UI resource ── Mapepire ── IBM i Db2
SharePoint Copilot component┘

The standalone host is available at ibmisalesworkspace.spteckapps.com, and the MCP endpoint is ibmisales.spteckapps.com/mcp. The server publishes the workspace under a versioned ui:// resource URI. Tools advertise which resource belongs with them; clients can discover the resource instead of each client hardcoding a particular UI bundle version.

The workspace includes customer, order, product, sales, sales representative, and sales-analysis views. It can page and filter lists, show details, and present a dashboard over the available sales data. The same React workspace can appear in a full browser window or inside a supported host, while the server remains responsible for data access.

One workspace in three environments

These screenshots show the IBM i Sales Workspace running as a standalone web app, inside Microsoft Copilot, and in Claude Desktop. The host framing changes, but the core sales workspace and its read-only data operations remain familiar.

Standalone web app

The web app gives the workspace the full browser window: users can move between the dashboard and records, inspect orders, and work with filters without starting from a conversation.

Sales analysis dashboard in the standalone web app.

The orders list with customer, date, and representative data.

The filter panel lets users refine the order view before applying their choices.

Microsoft Copilot

In Copilot, a person can start with a natural-language request such as “Show my sales dashboard.” The Copilot experience opens the interactive workspace alongside the conversation, where the person can continue exploring the dashboard or navigate to orders.

The Copilot entry point offers workspace and sales-task prompts.

The request and assistant response sit beside the interactive sales dashboard.

The same workspace can move from a dashboard request to browsing orders.

Claude Desktop

Claude Desktop can also host the MCP App. The conversation and the embedded interface complement one another: the assistant helps express the task, and the workspace presents structured records and analysis for further exploration.

The sales dashboard rendered inside Claude Desktop.

Customers remain available in the same interactive workspace.

The workspace presents its sign-in flow within the host rather than asking users to send credentials in chat.

What does natural-language interaction look like?

Imagine asking:

“Show me the orders for Acme in January 2026.”

An assistant can interpret the request, resolve the customer with a customer-search tool, and then call the order-list tool with the resolved customer ID and date range. The response can include structured data for the assistant and a workspace view for the person to inspect. They can then use the UI to filter, select a row, and open order details.

The conversation and the interface work together. Natural language is useful for expressing intent; a dedicated UI is often better for exploring a result set, checking exact values, or applying several filters. The person does not have to choose one interaction style forever.

Voice follows the same principle, with one important distinction: voice is a capability of the host experience, not something MCP Apps automatically adds. If an assistant or device supports speech input, it can turn spoken language into a request and invoke the same tools. The workspace then presents the response as UI. Voice input, transcription, permissions, and confirmation behavior vary by host; the MCP App itself should not assume that it can access a microphone.

Be precise about what the sample does today

The current IBM i workspace is read-only. Its tools support searching and reading customers, orders, products, sales, and sales representatives, plus sales summaries and a dashboard. It does not create or update orders. The demo data does not provide a verified order-status history, so the application does not invent one.

That constraint is intentional. Natural language can make a request easier to express, but it does not replace authorization, validation, or a confirmation step. If write operations are added later, they should be exposed as explicit server-side capabilities with appropriate identity checks and safeguards—not implemented as unrestricted SQL or assumed from a conversational instruction.

The sample also keeps the IBM i connection and database access on the server side. The embedded UI talks to the host through the MCP bridge rather than reaching directly into the database. Sign-in is handled in the workspace; the browser encrypts credentials before sending them to the server, and tool operations are scoped to the authenticated connection. The server remains the trust boundary.

What changes for application architecture?

MCP Apps encourage us to treat the UI as a portable surface over business capabilities, rather than the only place where those capabilities can be reached.

1. Design tools around business tasks

Tools should represent clear operations such as “search customers,” “list orders,” or “summarize sales.” Give them typed inputs and outputs, useful descriptions, bounded results, and explicit constraints. Tool design affects both what an assistant can reliably request and how the UI can retrieve data.

For example, when a customer name is ambiguous, the sales tools return candidates rather than silently choosing one. Date ranges require explicit years. For paginated data, the next-page cursor must be used with the original filters and sort order. These rules matter whether a request starts in a chat or in a filter panel.

2. Keep business rules and data access on the server

The server validates arguments, enforces the available access, and talks to IBM i. That gives conversational and graphical interactions a shared set of business operations. It also avoids trusting a client-side component to enforce the real security boundary.

3. Treat the UI as a host-rendered experience

An MCP App can use host-provided context and communicate through the MCP Apps bridge. It should not assume it owns the entire browser window, controls the host’s theme, or can make arbitrary network requests from its embedded frame. Layout, sizing, authentication, and permissions need testing inside each target host.

4. Build host adapters where they add value

The standalone web host and the SPFx Copilot component are not redundant. They provide different entry points and have different hosting responsibilities, even while they reuse the MCP tools and workspace. A native MCP Apps host may provide another entry point without requiring the application team to build a complete chat client.

The goal is not to eliminate host-specific code. It is to keep that code at the integration boundary and avoid rewriting the business application for every surface.

A practical development path

For a new or modernized business application, I would approach the work in this order:

1. Identify the real user tasks and the business systems that own the data.
2. Expose a small set of typed MCP tools with clear descriptions and explicit read/write boundaries.
3. Build a responsive MCP App UI that uses those tools through the host bridge.
4. Add a standalone host when users need a direct, familiar application outside an assistant.
5. Add platform-specific integrations—such as a Copilot component—when they fit the organization’s workflow.
6. Test the same user journeys across the actual target hosts, including identity, permissions, viewport sizing, errors, and data boundaries.

This is not a shortcut around good application design. It makes the contracts between the server, the UI, and each host more visible—and gives us another way to reuse the application.

The bigger idea: users choose the front door

Business applications have traditionally asked users to navigate to the application first and then figure out how to complete a task. With MCP tools and UI Apps, a user can start from the application, or from a compatible assistant that understands the request and opens the relevant business experience.

That is the paradigm shift I find exciting: one set of business capabilities, an interactive UI that can travel with them, and multiple supported ways for people to work. Not “one UI magically works everywhere,” but a shared application core that can meet users in different environments without pretending that host differences do not exist.

The IBM i Sales Workspace is an experiment in that direction. The standalone app and Copilot integration are already separate, testable entry points over shared MCP capabilities, and Claude Desktop demonstrates the same MCP App resource in a compatible assistant host.

For more detail, see the MCP Apps documentation, the official modelcontextprotocol/ext-apps project, and my earlier post on using MCP servers in a React application.

I’m excited to start this journey of sharing my thoughts, experiences, and knowledge about technology and software development.

What to Expect

Here you’ll find posts about:

• Web Development — Tips, tricks, and tutorials
• Software Architecture — Design patterns and best practices
• New Technologies — Reviews and explorations of the latest tools
• Personal Projects — Deep dives into things I’m building

Why Blog?

Writing helps me organize my thoughts and solidify my understanding of complex topics. If my posts help even one person solve a problem or learn something new, that’s a win!

Stay Tuned

I’ll be publishing new content regularly. Feel free to explore the site and check back often for new posts.

Thanks for reading, and welcome aboard!

Introduction

The Model Context Protocol (MCP) is an open protocol introduced by Anthropic that standardises how AI models — and any client application — connect to external tools and data sources. While the protocol gained widespread attention in the AI assistant world, its real power is as a universal, typed, and discoverable API layer that you can call from any front-end application, including React.

In this post I will walk you through a production-grade React component called My Team that uses an MCP server as its sole data source. The server wraps Microsoft Graph API calls and exposes them as typed MCP tools. The React app authenticates with Microsoft Entra ID (via MSAL), acquires a bearer token, connects to the MCP server over HTTP, and calls tools such as get_user, get_manager, and get_direct_reports.

The finished UI looks like this:

By the end of this post you will understand:

• How the MCP client connects to a server from the browser
• How custom React hooks abstract authentication, transport, and logging
• Which React hooks are used and why
• How infinite scroll pagination and dynamic page sizing are implemented
• The full architecture from the browser to Microsoft Graph

Architecture Overview

The diagram below shows every layer of the solution, from the React component tree down to Microsoft 365.

Key insight: The React app never calls Microsoft Graph directly. All data access is delegated to the MCP server. The browser only needs to know the MCP server URL and how to obtain a bearer token — the tool schema, pagination tokens, and Graph API details stay on the server side.

Project Structure

src/
├── atoms/                    # Jotai atoms (global state slices)
│   ├── authStateAtom.ts
│   └── mcpStateAtom.ts
├── config/
│   └── authConfig.ts         # MSAL config & loginRequest scopes
├── hooks/
│   ├── useAuth.ts            # MSAL authentication hook
│   ├── useMCPClient.ts       # MCP client hook
│   ├── useLogging.ts         # Structured logging hook
│   ├── useIndexedDBCache.ts  # IndexedDB caching hook
│   └── BrowserHTTPTransport.ts  # Custom MCP transport
└── components/
    └── myTeam/
        ├── IMyTeamProps.ts   # Props interface
        ├── MyTeam.tsx        # Main component
        ├── MyTeamSkeleton.tsx # Loading skeleton
        ├── useMyTeamStyles.ts # Emotion CSS-in-JS styles
        └── index.ts          # Public exports

Custom Hooks Deep Dive

useMCPClient — The MCP Transport Layer

This is the most important hook in the solution. It wraps the official @modelcontextprotocol/sdk client and exposes a clean API to React components.

import { useCallback, useRef, useEffect } from 'react';
import { useAtom } from 'jotai';
import { Client } from '@modelcontextprotocol/sdk/client/index.js';
import { mcpStateAtom } from '../atoms';
import { useIndexedDBCache } from './useIndexedDBCache';
import { BrowserHTTPTransport } from './BrowserHTTPTransport';

export function useMCPClient(): IUseMCPClientReturn {
  const [mcpState, setMcpState] = useAtom(mcpStateAtom);

  // 1-hour TTL for the tools list (avoids repeated /tools requests)
  const { getData, setData } = useIndexedDBCache<IMCPTool[]>(60 * 60 * 1000);

  // Persist the SDK Client and Transport across re-renders without
  // triggering re-renders when they change
  const clientRef = useRef<Client | null>(null);
  const transportRef = useRef<BrowserHTTPTransport | null>(null);

  // Deduplicate in-flight requests that arrive concurrently
  const pendingRequestsRef = useRef<Map<string, Promise<unknown>>>(new Map());

  const connect = useCallback(async (options: IMCPConnectOptions) => {
    const transport = new BrowserHTTPTransport({
      url: options.url,
      headers: options.headers ?? {},
      timeout: 30_000,
    });

    const client = new Client(
      { name: 'browser-mcp-client', version: '1.0.0' },
      { capabilities: {} }
    );

    transportRef.current = transport;
    clientRef.current = client;

    // Performs the MCP initialisation handshake
    await client.connect(transport);

    setMcpState(prev => ({
      ...prev,
      isConnected: true,
      isConnecting: false,
      sessionId: transport.getSessionId() ?? '',
      baseUrl: options.url,
      headers: options.headers ?? {},
    }));
  }, [setMcpState]);

  const callTool = useCallback(
    async (toolName: string, args: Record<string, unknown>) => {
      if (!clientRef.current) throw new Error('Not connected. Call connect() first.');

      return clientRef.current.callTool({ name: toolName, arguments: args });
    },
    []
  );

  // Clean up the SDK client when the component unmounts
  useEffect(() => {
    return () => {
      clientRef.current?.close();
      transportRef.current?.close();
    };
  }, [disconnect]);

  return { isConnected: mcpState.isConnected, connect, callTool, listTools, disconnect };
}

React hooks used in useMCPClient:

• useRef — Hold the Client and BrowserHTTPTransport instances without causing re-renders when they are assigned
• useRef (second) — In-memory Map for concurrent request deduplication
• useCallback — Stable references for connect, callTool, disconnect, and listTools so they can safely appear in dependency arrays
• useEffect — Cleanup — close the SDK client and transport when the hook’s owner component unmounts
• useAtom (Jotai) — Read and write the global mcpState (connection status, session ID, tools list, errors)

useAuth — MSAL Token Acquisition

useAuth wraps @azure/msal-react and adds automatic silent token refresh so the rest of the application never has to think about expiry.

import { useState, useEffect, useCallback, useRef } from 'react';
import { useMsal } from '@azure/msal-react';
import { useAtom } from 'jotai';
import { authStateAtom } from '../atoms';

const TOKEN_EXPIRY_BUFFER = 5 * 60 * 1000; // refresh 5 min before real expiry

export function useAuth(): IUseAuthReturn {
  const { instance, accounts } = useMsal();
  const [authState, setAuthState] = useAtom(authStateAtom);
  const [isLoading, setIsLoading] = useState(false);

  const tokenExpiryRef = useRef<number | null>(null);
  const isRefreshingRef  = useRef(false);

  const acquireToken = useCallback(
    async (request: RedirectRequest): Promise<string | undefined> => {
      const account = accounts[0];
      if (!account) return undefined;

      try {
        // Silent-first: use cached token from MSAL token cache
        const result = await instance.acquireTokenSilent({ ...request, account });
        tokenExpiryRef.current = result.expiresOn?.getTime() ?? null;
        return result.accessToken;
      } catch {
        // Fallback: interactive redirect when silent fails (e.g. consent required)
        await instance.acquireTokenRedirect(request);
      }
    },
    [instance, accounts]
  );

  // Poll every 5 minutes to refresh the token proactively
  useEffect(() => {
    const interval = setInterval(async () => {
      if (!isRefreshingRef.current && isTokenExpiringSoon()) {
        isRefreshingRef.current = true;
        await acquireToken({ scopes: loginRequest.scopes, forceRefresh: true });
        isRefreshingRef.current = false;
      }
    }, TOKEN_EXPIRY_BUFFER);

    return () => clearInterval(interval);
  }, [acquireToken]);

  return { isAuthenticated: !!accounts[0], acquireToken, isLoading, user: authState.user };
}

React hooks used in useAuth:

• useState — Track the isLoading flag for the login/logout UI
• useRef — Store tokenExpiryRef (expiry timestamp) and isRefreshingRef (guard against parallel refreshes) without triggering renders
• useCallback — Stable references for acquireToken, login, logout, and isTokenExpiringSoon
• useEffect — Start the background interval that proactively refreshes the token; clean up with clearInterval on unmount
• useAtom (Jotai) — Sync authenticated user information into global authStateAtom

useLogging — Structured Logging

useLogging provides levelled logging (DEBUG, INFO, WARN, ERROR, FATAL), an in-memory log history, and an optional remote endpoint. Every log entry is enriched with a timestamp, function name, and contextual data.

import { useCallback } from 'react';

export function useLogging(config: ILoggingConfig = {}) {
  const logInfo = useCallback(
    (functionName: string, message: string, additionalData?: Record<string, unknown>) => {
      const entry: ILogEntry = {
        timestamp: new Date().toISOString(),
        level: LogLevel.INFO,
        functionName,
        message,
        additionalData,
      };
      console.info(`[INFO] [${functionName}] ${message}`, additionalData ?? '');
      logHistory.push(entry);
    },
    []
  );

  // logDebug / logWarning / logError / logFatal follow the same pattern
  return { logDebug, logInfo, logWarning, logError, logFatal, getLogHistory };
}

React hooks used in useLogging:

• useCallback — Every logX function is memoised so that components that spread them into dependency arrays do not re-render unnecessarily

The MyTeam Component

Now that the hooks are clear, let’s look at how they are composed inside a single React component.

Props & State

export interface IMyTeamProps {
  userId?: string; // UPN or object ID of the user to show
}

// Inside the component
const [isLoading, setIsLoading]           = useState<boolean>(true);
const [currentUser, setCurrentUser]       = useState<ITeamMember | null>(null);
const [directReports, setDirectReports]   = useState<ITeamMember[]>([]);
const [skipToken, setSkipToken]           = useState<string | undefined>(undefined);
const [hasNextPage, setHasNextPage]       = useState(false);
const [isLoadingMore, setIsLoadingMore]   = useState(false);
const [isFetching, setIsFetching]         = useState(false);
const [containerHeight, setContainerHeight] = useState(600);
const [error, setError]                   = useState<string>('');

Dynamic Page Size with useMemo

Instead of hard-coding a $top value, the component measures its own height and calculates how many rows are visible:

const ITEM_HEIGHT    = 200; // approximate card height in px
const HEADER_OFFSET  = 250; // space taken by the current-user card + header

const pageSize = useMemo(() => {
  const visibleRows  = Math.floor((containerHeight - HEADER_OFFSET) / ITEM_HEIGHT);
  // Pre-load 2× the visible area for smooth scrolling
  return Math.max(6, visibleRows * 2);
}, [containerHeight]);

useMemo ensures the calculation only runs when containerHeight changes — not on every render.

Observing Container Size with useEffect + ResizeObserver

Because the component can live inside a resizable dashboard tile, it listens to dimension changes:

const containerRef = useRef<HTMLDivElement>(null);

useEffect(() => {
  const container = containerRef.current;
  if (!container) return;

  const observer = new ResizeObserver(entries => {
    for (const entry of entries) {
      const height = entry.contentRect.height;
      if (height > 0) setContainerHeight(height);
    }
  });

  observer.observe(container);

  // Cleanup: always disconnect the observer to avoid memory leaks
  return () => observer.disconnect();
}, []); // Empty array = set up once on mount

Preventing Double-Fetch with useRef

React 18’s Strict Mode mounts components twice in development. A useRef flag guards against fetching twice without introducing complex state:

const hasFetchedRef = useRef(false);

useEffect(() => {
  if (userId && !hasFetchedRef.current) {
    hasFetchedRef.current = true;
    loadTeamData();
  }
}, [userId]);

Initial Data Load — Connecting to the MCP Server

The initial load sequence follows four steps:

const loadTeamData = async (): Promise<void> => {
  setIsLoading(true);

  // 1. Acquire bearer token via MSAL (silent → interactive fallback)
  const token = await acquireToken(loginRequest);

  // 2. Connect to the MCP server, passing the token in the Authorization header
  await connect({
    url: MCP_SERVER_URL,
    headers: { Authorization: `Bearer ${token}` },
  });

  // 3. Call the get_user tool to resolve the current user's details
  const userResult = await callTool('get_user', { userId });
  const { user } = JSON.parse(userResult.content[0].text);
  setCurrentUser(user);

  // 4. Call get_manager (optional — user may be at the top of the org)
  try {
    const managerResult = await callTool('get_manager', { userId });
    const manager = JSON.parse(managerResult.content[0].text);
    // Use manager.id to fetch peers (direct reports of the manager)
    await fetchPeers(manager.id);
  } catch {
    logInfo('loadTeamData', 'No manager found — user is at top level');
  }

  // 5. Fetch first page of direct reports
  await fetchDirectReports();

  setIsLoading(false);
};

Infinite Scroll Pagination

The MCP server returns an OData-style @odata.nextLink or a skipToken property when there are more pages. The component appends pages as the user scrolls:

const handleScroll = useCallback(
  (e: React.UIEvent<HTMLDivElement>) => {
    const { scrollTop, scrollHeight, clientHeight } = e.currentTarget;
    const scrollRatio = (scrollTop + clientHeight) / scrollHeight;

    // Trigger the next page load when 80 % of the content is visible
    if (scrollRatio >= 0.8 && hasNextPage && !isLoadingMore && !isFetching) {
      fetchDirectReports(skipToken, /* isLoadMore */ true);
    }
  },
  [hasNextPage, isLoadingMore, isFetching, skipToken, fetchDirectReports]
);

When isLoadMore is true, new results are appended rather than replacing the list:

if (isLoadMore) {
  setDirectReports(prev => [...prev, ...parseResult.reports]);
} else {
  setDirectReports(parseResult.reports);
}

Loading Skeleton

While the initial fetch is in progress, MyTeamSkeleton renders Fluent UI skeleton cards instead of a spinner, providing a content-aware loading state:

if (isLoading) return <MyTeamSkeleton count={6} />;

MyTeamSkeleton uses the same useMyTeamV2Styles hook so the layout is consistent during and after loading.

All React Hooks at a Glance

MyTeam component

• useState — currentUser, directReports, skipToken, hasNextPage, isLoading, isLoadingMore, isFetching, containerHeight, error
• useEffect — Mount the ResizeObserver; trigger initial data load once
• useCallback — Stable references for parseDirectReports, fetchDirectReports, handleLoadMore, handleScroll, and action handlers
• useMemo — Calculate pageSize from containerHeight
• useRef — containerRef (DOM node), hasFetchedRef (double-fetch guard)
• React.memo — Skip re-renders when props have not changed

useMCPClient hook

• useRef — clientRef, transportRef, pendingRequestsRef
• useCallback — connect, disconnect, listTools, callTool, selectTool, clearCache
• useEffect — Disconnect and clean up on unmount

useAuth hook

• useCallback — acquireToken, login, logout, isTokenExpiringSoon
• useRef — tokenExpiryRef, isRefreshingRef
• useEffect — Background token refresh interval

useLogging hook

• useCallback — All logX functions

Setting Up the MCP Client in Your Own React App

Follow these steps to embed an MCP server in a React project:

1. Install the SDK and MSAL

npm install @modelcontextprotocol/sdk @azure/msal-browser @azure/msal-react jotai

2. Configure MSAL

// src/config/authConfig.ts
import { Configuration, LogLevel } from '@azure/msal-browser';

export const msalConfig: Configuration = {
  auth: {
    clientId: '<your-app-client-id>',
    authority: 'https://login.microsoftonline.com/<your-tenant-id>',
    redirectUri: window.location.origin,
  },
  cache: { cacheLocation: 'sessionStorage' },
};

export const loginRequest = {
  scopes: ['api://<your-mcp-server-app-id>/user_impressonation'],
};

3. Implement BrowserHTTPTransport

The official MCP SDK ships a Node.js StreamableHTTPClientTransport. For the browser you need a fetch-based equivalent:

// src/hooks/BrowserHTTPTransport.ts
import type { Transport } from '@modelcontextprotocol/sdk/shared/transport.js';
import type { JSONRPCMessage } from '@modelcontextprotocol/sdk/types.js';

export class BrowserHTTPTransport implements Transport {
  private _url: string;
  private _headers: Record<string, string>;
  private _sessionId?: string;

  constructor(options: { url: string; headers: Record<string, string>; timeout?: number }) {
    this._url = options.url;
    this._headers = options.headers;
  }

  async send(message: JSONRPCMessage): Promise<void> {
    const response = await fetch(this._url, {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'mcp-session-id': this._sessionId ?? '',
        ...this._headers,
      },
      body: JSON.stringify(message),
    });

    if (response.ok) {
      const sessionHeader = response.headers.get('mcp-session-id');
      if (sessionHeader) this._sessionId = sessionHeader;

      const data = await response.json();
      this.onmessage?.(data);
    }
  }

  getSessionId() { return this._sessionId; }

  onessage?: (message: JSONRPCMessage) => void;
  onerror?:   (error: Error) => void;
  onclose?:   () => void;

  async start() { /* no-op for HTTP */ }
  async close() { this._sessionId = undefined; this.onclose?.(); }
}

4. Create the Jotai Atom

// src/atoms/mcpStateAtom.ts
import { atom } from 'jotai';

export interface IMCPState {
  isConnected: boolean;
  isConnecting: boolean;
  sessionId?:  string;
  tools:       IMCPTool[];
  error?:      string;
  baseUrl?:    string;
  headers?:    Record<string, string>;
}

export const mcpStateAtom = atom<IMCPState>({
  isConnected: false,
  isConnecting: false,
  tools: [],
});

5. Wrap Your Application

// src/index.tsx
import { MsalProvider } from '@azure/msal-react';
import { Provider as JotaiProvider } from 'jotai';
import { PublicClientApplication } from '@azure/msal-browser';
import { msalConfig } from './config/authConfig';

const msalInstance = new PublicClientApplication(msalConfig);

root.render(
  <MsalProvider instance={msalInstance}>
    <JotaiProvider>
      <App />
    </JotaiProvider>
  </MsalProvider>
);

6. Use the Hook

import { useAuth }      from './hooks/useAuth';
import { useMCPClient } from './hooks/useMCPClient';
import { loginRequest } from './config/authConfig';

const MY_MCP_SERVER = 'https://my-mcp-server/mcp';

export const MyComponent: React.FC = () => {
  const { acquireToken } = useAuth();
  const { connect, callTool } = useMCPClient();
  const [data, setData] = useState<unknown>(null);

  useEffect(() => {
    (async () => {
      const token = await acquireToken(loginRequest);
      await connect({ url: MY_MCP_SERVER, headers: { Authorization: `Bearer ${token}` } });

      const result = await callTool('get_user', { userId: 'me' });
      setData(JSON.parse(result.content[0].text));
    })();
  }, []);

  return <pre>{JSON.stringify(data, null, 2)}</pre>;
};

Key Takeaways

• MCP as a universal API layer — your React component never imports any Graph SDK. Tools are discoverable, typed, and versioned on the server.
• useRef for mutable values that must not trigger renders — the SDK Client instance, transport, and request-deduplication map all live in refs.
• useMemo for derived state — the page size is computed from container dimensions, cached by useMemo, and passed as a tool argument.
• useCallback everywhere — all async handlers are wrapped in useCallback so they can appear in useEffect dependency arrays without causing infinite loops.
• ResizeObserver in a useEffect — a clean teardown pattern (return () => observer.disconnect()) prevents memory leaks.
• React.memo — wrapping both MyTeamV2 and MyTeamSkeleton prevents unnecessary re-renders when parent state changes.
• Skeleton loading — matching the layout of real cards during load eliminates Cumulative Layout Shift (CLS).
• IndexedDB caching — the tools list is cached for one hour. The bearer token changes per session; the tool schema does not.

Resources

• Model Context Protocol — Official Documentation
• @modelcontextprotocol/sdk on npm
• MSAL React — Microsoft Authentication Library
• Jotai — Primitive and flexible state management for React
• Fluent UI React Components
• Microsoft Graph API — Users resource type