Hi TMS team,
we are integrating TTMSMCPCloudAI (v1.7.3.0) into a Delphi ERP (document analysis on attachments: PDF, images, e-mails). Single-shot requests work very well. What we are missing is a supported way to ask follow-up questions in the same conversation without re-uploading all files on every call. Looking at the source, the pieces are almost there, but not reachable from application code:
1. previous_response_id exists, but is private and internal only
FPrevIDResponse (TMS.MCP.CloudAI.pas ~line 516) is only set inside the OpenAI tool-call round trip (FPrevIDResponse := '"previous_response_id": "' + lVRespID + '",', ~line 2727) and is reset to '' by Execute (~line 1503/3431). The response id (lvJSON.GetValue<string>('id'), ~line 2617) is also not exposed to the caller.
Request: expose the last response id (e.g. LastResponseID or a field on the request result passed to OnExecuted) and add a public PreviousResponseID: string property that is serialized for the OpenAI Responses API. With that, a follow-up question costs only the question — OpenAI keeps files and history server-side.
2. AssistantRole holds exactly one assistant message
GetPostData (~line 1030) serializes FAssistantRole.Text as a single {"role":"assistant"} message before the user context. For a real multi-turn history (user/assistant/user/assistant…) we have to concatenate everything into that one message, which degrades quality and differs per provider.
Request: a provider-neutral History (collection of role/content items, or a Messages list) that GetPostData serializes in order for all services (OpenAI, Claude, Gemini, Mistral, Ollama, …). AssistantRole could stay as a convenience for the single-message case.
3. Files are re-serialized into every request
FFiles is merged into the user message on every Execute (~lines 1199–1225). Combined with (1) this is solved for OpenAI; for the other providers it would at least help to document that files are resent per call (cost/latency), or to allow Execute without re-sending already uploaded files where the provider supports file IDs.
4. Minor: Settings.CustomOptions is the only extension point
Today we can inject previous_response_id ourselves via Settings.CustomOptions (it lands top-level in the OpenAI body), but that collides with other top-level options we already need there (text.format for structured output) and is OpenAI-specific and undocumented. A dedicated property would avoid that workaround.
Why it matters for us: the typical ERP use case is "summarize / extract this invoice, then ask two or three clarifying questions". Resending a 10-page PDF for each follow-up multiplies cost and latency, and a one-message assistant history limits the quality of the follow-ups.
Thanks for considering — happy to test a beta.
Best regards