Create and execute durable Chat documents — conversations that live in the user's workspace.
|
|
https://api.charmiq.ai/mcp/chatcreate_chat | |
read_chat | |
delete_chat | |
execute_chat | |
retry_chat |
create_chat, read_chat, and delete_chat are convenience wrappers around the VFS server (create_file with type='chat', read_file, delete_file). If you're already using VFS, you can call those directly — same result.create_chat to mint a new Chat document. Returns a charmiq://chat/<id> URI.execute_chat(uri, message, agentIds?) to send the user's first message and run a completion. Both the message and the Charm's response are written to the document.read_chat(uri) any time you want to inspect the current state.delete_chat(uri) when the conversation is done.agentIds is omitted, the system default Chat agent runs. Otherwise the Charms you name run in sequence — each gets the prior turns as context.execute_chat may fail with mcp/consent-required. The user's message is already in the document; only the Charm's failed turn needs replacing.retry_chat(uri) with the same Chat URI. It replaces the failed Agent turn — your application doesn't have to re-post the user message.execute_chat accepts context dependents to attach material the Charm should see when answering: documents, folders, uploaded files. Each dependent carries:dependentType | richtext, folder, or asset |
dependentId | {id} portion of the corresponding charmiq:// URI |
list_dir, semantic_search, or by parsing a charmiq:// URI you already have. Folders attach as containers; the Charm sees their contents.retry_chat after consent, not execute_chat. Re-sending the user message would duplicate it in the document.list_agents returns the IDs to pass into execute_chat.execute_chat.