MCP fundamentals

The Model Context Protocol (MCP) is an open standard for connecting AI applications to the tools and data they need. It defines how an AI application finds out what a server can do and how it asks the server to do it, using JSON-RPC 2.0 messages.

If you’ve published a REST service through Integration Broker, the idea will feel familiar: a provider publishes a catalog of operations, each with a schema, and any compliant consumer can discover and call them. MCP applies that idea to AI assistants. Application Designer AI Assist is an MCP server, so it works with any IDE or chat client that speaks MCP.

Hosts, clients, and servers

MCP has three roles:

Role	What it is	In AI Assist
Host	The AI application you work in. It owns the conversation and the LLM, and asks for your approval before tools run.	Your IDE or chat client, such as VS Code, Cursor, Claude Code, or Claude Desktop
Client	A connector inside the host. Each client talks to exactly one server.	Created by the host when you add the AI Assist server to its configuration
Server	A program that exposes capabilities through MCP.	The AI Assist MCP server, connected to your PeopleSoft database

One detail matters for PeopleSoft security reviews: a server never sees the whole conversation. The host sends the AI Assist server only what each tool call needs, such as a record name. Your chat history, and anything from other servers, stays with the host.

What a server offers

A server can expose three kinds of capabilities, each controlled by a different party:

Primitive	Controlled by	What it is	In AI Assist
Tools	The model	Functions the LLM can call, each with a JSON Schema for its inputs	Lookups such as `describe_record` and `search_code`
Resources	The application	Read-only context, identified by a URI, that you or the host attach to the conversation	Definitions as documents, such as `psft://record/JOB`
Prompts	The user	Reusable message templates, often offered as slash commands	Workflows such as “explain this component”

Tools do most of the work in AI Assist: the LLM decides which definitions to look up as it works through your question.

Clients can offer capabilities too. The one that matters here is elicitation, which lets a server ask the user a question in the middle of a request. On clients that support it, AI Assist can use elicitation to confirm before it runs an expensive data query.

How a tool call flows

Since version 2026-07-28, MCP is stateless. There’s no connection handshake, and every request is self-contained: it carries the protocol version and the client’s capabilities in a _meta field, so any instance of a server can answer any request.

Discover (optional). The client can call server/discover to learn which protocol versions and capabilities the server supports, along with usage instructions for the LLM.
List the tools. The client calls tools/list and passes the tool definitions to the LLM.
Choose a tool. While working on your question, the LLM picks a tool and fills in its arguments. The host shows you the call and, depending on your settings, asks for approval.
Call the tool. The client sends tools/call with the tool’s name and arguments.
Use the result. The server returns the result, and the LLM uses it to continue its answer, often by calling more tools.

Discovery

A server/discover result tells the client what the server supports:

{
  "resultType": "complete",
  "supportedVersions": ["2026-07-28"],
  "capabilities": { "tools": {}, "resources": {}, "prompts": {} },
  "instructions": "Read-only access to PeopleTools metadata in the HRDEV database. Definition names are uppercase. Custom definitions start with ZZ_. Use search_definitions when you're not sure of a name.",
  "_meta": {
    "io.modelcontextprotocol/serverInfo": {
      "name": "aipeoplesoft-mcp",
      "version": "1.0.0"
    }
  },
  "ttlMs": 3600000,
  "cacheScope": "private"
}

The instructions field is the place to tell the LLM about your environment, such as which database it’s connected to and the prefix your team uses for custom definitions.

A tool definition

Each entry in the tools/list result describes one tool:

{
  "name": "describe_record",
  "title": "Describe record",
  "description": "Describe a PeopleSoft record definition: record type, SQL table name, fields in order with type, length, and key flags, subrecords, indexes, and the pages that use it. Record names are case-insensitive.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "record": {
        "type": "string",
        "description": "Record name, for example JOB or VOUCHER_LINE",
        "pattern": "^[A-Za-z][A-Za-z0-9_]{0,14}$"
      },
      "include_pages": {
        "type": "boolean",
        "description": "Also list the pages that use the record",
        "default": true
      }
    },
    "required": ["record"],
    "additionalProperties": false
  },
  "annotations": {
    "readOnlyHint": true,
    "openWorldHint": false
  }
}

The parts that matter most:

description is written for the LLM. It’s how the model decides when to use the tool, so it spells out exactly what comes back.
inputSchema is standard JSON Schema. Its pattern encodes the PeopleSoft rule that a record name is at most 15 characters, so bad input is rejected before any SQL runs.
annotations tell the host that the tool only reads, and only from a closed set of data. The specification tells hosts to treat annotations as untrusted unless the server itself is trusted, so AI Assist doesn’t rely on them. Read-only access is enforced by the database account.

The call and its result

The client sends the tool’s name and arguments, plus the required _meta fields:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "describe_record",
    "arguments": { "record": "job" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {},
      "io.modelcontextprotocol/clientInfo": {
        "name": "ExampleIDE",
        "version": "3.2.0"
      }
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "resultType": "complete",
    "structuredContent": {
      "record": "JOB",
      "recordType": "SQL Table",
      "sqlTable": "PS_JOB",
      "keys": ["EMPLID", "EMPL_RCD", "EFFDT", "EFFSEQ"],
      "fields": [
        { "name": "EMPLID", "type": "Character", "length": 11 },
        { "name": "EMPL_RCD", "type": "Number", "length": 3 },
        { "name": "EFFDT", "type": "Date" },
        { "name": "EFFSEQ", "type": "Number", "length": 3 },
        { "name": "DEPTID", "type": "Character", "length": 10 }
      ],
      "pages": ["JOB_DATA1"]
    },
    "content": [
      {
        "type": "text",
        "text": "{\"record\":\"JOB\",\"recordType\":\"SQL Table\",…}"
      }
    ],
    "_meta": {
      "io.modelcontextprotocol/serverInfo": {
        "name": "aipeoplesoft-mcp",
        "version": "1.0.0"
      }
    }
  }
}

The result carries the data twice. structuredContent is JSON that the client can check against the tool’s output schema. The text block holds the same JSON as a string, which the specification recommends so that older clients can still read the result.

When something goes wrong

MCP separates two kinds of errors:

Protocol errors mean the request itself is wrong, for example because it names a tool that doesn’t exist. They come back as JSON-RPC errors.
Tool execution errors mean the request was valid, but the tool couldn’t do what was asked. They come back as a normal result with isError: true and a message the LLM can act on.

AI Assist writes its tool errors so the model can correct itself and try again:

{
  "jsonrpc": "2.0",
  "id": 8,
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "Record JOBB doesn't exist. Closest matches: JOB, JOB_EARNS_DIST, JOBCODE_TBL."
      }
    ],
    "isError": true
  }
}

Transports

MCP messages travel over one of two standard transports:

stdio
Streamable HTTP

The host starts the server as a local subprocess and exchanges JSON-RPC messages with it over standard input and output, one message per line. The server writes its logs to standard error.

Runs on: each developer’s machine
Database credentials: in the developer’s local configuration or environment
Best for: individual developers, and trying AI Assist out

The server runs as a network service with a single HTTPS endpoint, and the client sends each message as an HTTP POST. Remote servers authenticate users through MCP’s authorization specification, which is based on OAuth 2.1, so developers can sign in with your identity provider. Servers must also validate the Origin header of every request, which protects them from malicious websites.

Runs on: a server close to the PeopleSoft database
Database credentials: held centrally by the service, never on developer machines
Best for: teams that want one managed, audited endpoint

The tools behave the same over either transport.

Versions and compatibility

MCP versions are named by their release date. Version 2026-07-28 changed how connections work:

No more handshake or sessions. Earlier versions, up to and including 2025-11-25, opened each connection with an initialize handshake and kept state for the session. Now each request stands on its own.
server/discover replaces the handshake as the way to learn a server’s versions and capabilities.

IDEs and chat clients adopt new versions at different speeds, so the AI Assist server is dual-era: it accepts modern, self-contained requests, and still supports the initialize handshake for older clients. You don’t need to know which version your IDE uses.

AI Assist also avoids features that the current specification deprecates: sampling (a server asking the host’s LLM for completions), roots, protocol-level logging, and the old HTTP+SSE transport.

Security in the protocol

The MCP specification keeps people in control:

Hosts must get your consent before a tool runs, and should show you what’s being called.
Servers must validate every input, enforce access controls, and rate-limit tool calls.

AI Assist adds its own safeguards underneath: a read-only database account, an allow-list of tables, row and time limits on every query, and an audit log. Built-in guardrails summarizes them, and How the server works shows where each one sits.