Agent Kunjani

List the Kunjani decks the authenticated user can see (id, name, description, dice option, suits, question order). Use it to find an existing deck and reuse its id with publish_activity_batch or the manage_* tools for an idempotent update instead of creating a duplicate. Read-only.

list_decks

List, create, update, or delete the learning outcomes of a Kunjani deck, including re-wiring which questions an outcome is linked to via question_ids. Write outcomes as 3-6 specific, observable, learner-facing statements of what the player should be able to do after the deck (e.g. "Recognise the reputational impact of poor service"), not broad topics; every activity should advance at least one. create requires outcome.description. Update and delete only work on outcomes the deck owns; outcomes listed with kind "via_questions" belong to another deck and cannot be changed from here.

manage_outcomes

List, get, create, update, or delete individual questions (activities) of a Kunjani deck. Use this for targeted edits; use publish_activity_batch for bulk authoring. When writing, follow the three-block rule: text is the player-facing trigger (never reveal the answer), answer is the AI grader answer key, and assessment_notes are flexible grading rules (accept synonyms and real-world examples, state minimum valid points, no rigid tier rubrics) plus any media transcript because the grader is text-only. create requires question.suit_name, question.text, and question.answer; suit_name must name a suit on the deck (Jolt, Advance, Mystery, Oops, Explain, or Demonstrate). OMIT question.name so Kunjani auto-numbers within the suit (J1, O1, D1); only set a name to pin a slot. Update changes only the fields you supply. Images are URL-based only (picture_url / facilitator_picture_url, jpeg/png/gif/webp, max 16 MB; remove_picture and remove_facilitator_picture clear the slots). action "delete" is PERMANENT, removes the question from EVERY deck it is shared with, and is two-step: the first call returns a summary plus a confirm_token; call again echoing it. Never invent a confirm_token.

manage_questions

Get, create, update, delete, or reorder the questions of ONE Kunjani deck. Typical flow: create the deck, seed its outcomes with manage_outcomes, then add activities with publish_activity_batch or manage_questions. action "create" makes an EMPTY deck (deck.name required); every other action requires deck_id; update changes only the deck fields you supply. "get" returns question_order, the display order the deck overview and games use (it can differ from creation order); "reorder_questions" changes it and must list EVERY question on the deck. dice_option "loaded" plays activities in a fixed order (default, for scaffolded decks); "random" fires a random activity per suit (use only for pure-recall drills). Deck thumbnails are URL-based only: deck.picture_url fetches a public image (jpeg/png/gif/webp, max 16 MB); deck.remove_picture true clears it. action "delete" is PERMANENT and two-step: the first call returns a summary of what would be deleted plus a confirm_token; call again echoing that confirm_token to actually delete. Never invent a confirm_token. After creating or updating a deck, share a deck link from the response with the user: deck.teams_url when the user is in Microsoft Teams or M365 Copilot, otherwise deck.url.

manage_deck

Create or update a Kunjani deck and publish a batch of training activities into it in one call. When deck.id targets an existing deck, supplied deck fields (name, description, visibility, collaborations, dice_option, picture_url) are applied and omitted fields are left untouched. mode "publish" persists; mode "validate" only previews and writes nothing (no deck, outcome, or activity is created or updated). Author using the Agent K method: (1) design 3-6 learning outcomes first (specific, observable, learner-facing, e.g. "Handle an unhappy customer without escalation") and tag every activity with the outcome(s) it advances via its outcomes field. (2) Each activity has three parts: text is what the player sees, a scenario or trigger that must NOT teach or reveal the answer; answer is the answer key the AI grader scores against (specific, bulleted key points); assessment_notes are grading rules and context (accept synonyms and real-world examples, state the minimum valid points, do NOT write rigid tier rubrics, and include any media transcript because the grader is text-only). (3) suit sets the activity type: Jolt (quick recall, 30-60s), Advance (praise a good action then unpack its benefits, 60-90s), Mystery (creative photo/video/lateral thinking, 90-300s), Oops (a mistake scenario then unpack the consequences, 60-90s), Explain (summarise/compare/analyse, 90-120s), Demonstrate (perform, role-play, or submit media, 90-300s). Keep each activity to the one thing it tests, and OMIT each activity name so Kunjani auto-numbers it within its suit (J1, A1, M1, O1, E1, D1); only set a name to pin a specific slot. After publishing, share a deck link from the response with the user: deck.teams_url when the user is in Microsoft Teams or M365 Copilot, otherwise deck.url.

publish_activity_batch