CData Connect AI — Exchange Skill

⚠️ Prerequisites — load these first

• connect-ai-base skill

Before proceeding, locate and read the connect-ai-base skill. If it is not available in the current environment (not loaded, not enabled, or not installed), stop immediately. Do not proceed with the task. Tell the user that the connect-ai-base skill is required and ask them to install and enable it before continuing.

This skill provides Exchange-specific guidance for querying Microsoft Exchange data through CData Connect AI. It composes on top of the connect-ai-base skill, which handles the discovery workflow, error recovery, SQL dialect, and three-part query naming convention.

Precedence

This skill replaces getInstructions for the Exchange driver. Do not call getInstructions for Exchange — the guidance it provides is already incorporated here and in the per-surface references. Proceed directly to getSchemas (to identify the surface — see below) and then schema discovery (getTables / getColumns) after identifying the Exchange connection via getCatalogs.

Exchange exposes two API surfaces

An Exchange connection presents one of two completely different surfaces, determined by the CData Schema connection property. The surface changes the entire object model — table names, the way mailbox folders are exposed, column-naming conventions, available stored procedures, and write mechanics all differ. The surface cannot be inferred from the connection name, so the first move on any Exchange connection is to identify it with getSchemas.

Always run getSchemas as the FIRST tool call against any Exchange connection — before any queryData, getTables, or getColumns call. Do not infer the surface from the connection name. A name may carry an _MSGraph, _EWS, or similar hint, but this is not a reliable surface indicator. The schema returned by getSchemas is the only authoritative signal: MSGraph → Graph surface, EWS → EWS surface.