Read-only by design
Connects with a dedicated database account that can only read, limited to the tables the tools need.
PeopleSoft development happens in Application Designer, and everything you build there (records, fields, pages, components, PeopleCode, SQL objects, Application Engine programs) is stored as metadata in the PeopleSoft database. A general-purpose AI coding assistant can’t see any of it. Ask it about PeopleSoft and it guesses from what it knows about the delivered system, with no knowledge of your customizations.
Application Designer AI Assist closes that gap. It connects the LLM in your IDE to a Model Context Protocol (MCP) server that looks up PeopleTools definitions directly in your database, so answers, explanations, and generated code are grounded in your system. It works alongside Application Designer: you ask in your IDE, then apply the results in Application Designer.
The Guides follow questions like these from start to finish.
You ask a question in an AI-enabled IDE or chat client such as VS Code, Cursor, or Claude Code. Any client that supports MCP will work.
The LLM picks its tools. It decides which lookups it needs and calls the MCP server,
for example describe_record or search_code.
The MCP server queries PeopleTools metadata in tables such as PSRECDEFN,
PSRECFIELD, PSPCMTXT, and PSPNLGRPDEFN, using a dedicated read-only database account.
The LLM answers from real definitions. It explains the design or drafts code, which you review and apply in Application Designer.
The MCP server is the heart of AI Assist. Because it speaks the open Model Context Protocol, it isn’t tied to one IDE or one LLM vendor: the same server works with any MCP client.
It exposes PeopleTools knowledge as a small set of focused tools. The Tools reference documents each one in detail.
| Tool | What it returns |
|---|---|
search_definitions |
Records, fields, pages, components, and other definitions that match a name, description, or navigation label |
describe_record |
Fields, keys, types, lengths, record type, subrecords, indexes, and the pages that use the record |
describe_component |
Pages, search record, records, navigation, and the PeopleCode that runs in the component |
describe_app_engine |
Sections, steps, and actions of an Application Engine program, with their SQL and PeopleCode |
get_peoplecode |
PeopleCode for a record field, component, page, application class, or Application Engine step |
get_sql |
The text of a SQL object, SQL view, or Application Engine statement |
search_code |
Full-text search across all PeopleCode and SQL |
find_references |
Pages, components, records, and queries that refer to a record, field, or page |
get_translate_values |
Translate (XLAT) values for a field, as of a date |
get_security |
Roles and permission lists that grant access to a component |
run_select |
A row-limited, read-only SELECT against the application tables your administrator allows |
The PeopleTools tables are the same on every database platform PeopleSoft supports, so the tools behave the same wherever your PeopleSoft database runs.
Read-only by design
Connects with a dedicated database account that can only read, limited to the tables the tools need.
Bounded queries
Row limits and timeouts on every call, so an exploratory question can’t bog down the database.
Credentials stay put
Database credentials live with the MCP server. They never appear in prompts or LLM traffic.
Every call audited
Each tool call is logged: who asked, which tool ran, and what it queried.
The Security section explains each safeguard, and how AI Assist handles risks such as prompt injection.