Table of Contents

Getting started with Cloud AI Tool Sets

This page covers the shortest path to a model that can call your machine: create a tool set, configure it, attach it to a TTMSMCPCloudAI, and send a prompt. For the tool-by-tool detail of each shipped set, see the user guide.

Prerequisites

  • Delphi 11 Alexandria or newer (or C++Builder) with TMS AI Studio installed.
  • A VCL or FMX application with a TTMSMCPCloudAI on a form, or created in code, with an API key already configured. See Getting started with Cloud AI.
  • A service that supports function calling. Not every provider does — ask the component with AI.GetActiveServices(True) rather than assuming.

Add TMS.MCP.CloudAIToolSets to your uses clause. It pulls in TMS.MCP.CloudAI for you, but list that unit as well if you also touch the component's own Tools collection.

Pick a set

Four tool sets ship with the product. Each is a component you create once and attach once:

Class Gives the model Configure first
TTMSMCPCloudAILogger A message dialog, the console, and a timestamped log file LogFileName
TTMSMCPCloudAIFileSystem Listing, reading, writing, copying, and moving files nothing
TTMSMCPCloudAIDataSet Schema, navigation, reading, editing, and locating records DataSource, and an open dataset
TTMSMCPCloudAIEmail Sending mail, counting mail, and reading one message The SMTP and POP3 properties

Attach it

Setting AI is the entire registration step. Nothing else has to be called, and nothing has to be added to the component's own Tools collection:

procedure TForm1.SetUpLogging;
begin
  FLogger := TTMSMCPCloudAILogger.Create(Self);

  { LogFileName is the fallback the LogToFile tool uses when the model does
    not supply a logfile argument of its own. With neither, the tool raises. }
  FLogger.LogFileName := TPath.Combine(TPath.GetDocumentsPath, 'assistant.log');

  { Setting AI is the whole registration step. From here on every
    AI.Execute call offers the three logging tools to the model. }
  FLogger.AI := AI;
end;

procedure TForm1.btnSummariseClick(Sender: TObject);
begin
  if AI.Busy then
    Exit;

  AI.SystemRole.Text :=
    'Summarise the text the user gives you, then write the summary to the ' +
    'log file with the LogToFile tool.';
  AI.Context.Text := memoInput.Lines.Text;
  AI.Execute;
end;

From here on, every AI.Execute call merges the set's tools with the component's own and offers the union to the model. A set attached to no component contributes nothing; a set attached to two components in turn contributes to whichever one it is currently pointing at.

What the model sees

A tool set declares its tools in its constructor, so the Tools collection is already populated the moment the component exists. Each entry is an ordinary TTMSMCPCloudAITool — the same class you would fill in yourself when declaring tools by hand — carrying a Name, a Description, and a Parameters collection. The model chooses between them from those descriptions alone, which is why a prompt that names the tool you expect ("record each finding with LogToFile") produces far more predictable runs than one that leaves the choice open.

Keep the boundary explicit

A tool set is genuine access to the machine, not a sandbox. The file system set will read and write any path the model names; the dataset set will modify the record the dataset is positioned on; the email set will send to any address. Two levers narrow that:

  • Enabled on individual tools. Clearing it withholds a tool from the model entirely — the supported way to offer a read-only file system.
  • The system role. It is the only thing that constrains which folder, which table, or which recipient, so state the limits there explicitly.

See also