Giljo HQ

Accept a finished agent's work and seal the job (complete -> closed), after reviewing it. Orchestrator only: pass caller_job_id=<your own job_id>; a worker ends at complete_job and is refused (ORCHESTRATOR_ONLY). A sealed job is not woken by new messages. If the agent went silent and never reported, do NOT decommission it: call complete_job(job_id, result=<what you verified>) yourself, then finalize. If that returns COMPLETION_BLOCKED, settle its ledger with report_progress(job_id, todo_items=[...], replace=true), drain its action-required messages, and retry.

finalize_job

Fetch the completion result of a finished agent job. Returns the structured result dict (summary, artifacts, commits) stored when the agent called complete_job. Use this to read what a predecessor agent accomplished.

get_agent_result

Fetch product/project context by category in one call (pass a list). categories=['project'] returns one project's description and mission and names it two ways: project_alias is the short permanent share code (e.g. A1B2C3), taxonomy_alias the human-readable serial (e.g. BE-0007). Token costs per category: see categories. Never pass tenant_key.

get_context

Return the GiljoAI cross-tool guide: the routing/judgment layer for the project/task tools (chain convention, Edition Scope, read-vs-write routing, the staging -> human-gate -> implement lifecycle). No arguments. Call once, early, to become competent before creating or reading projects and tasks.

get_giljo_guide

Fetch the prompt that starts implementation on a project that is staged and has been approved to start. This RETURNS a prompt; it does not run anything. Two things must already be true: the project finished staging, and a human approved the start (the dashboard's Implement button, or launch_implementation). If they are not, you get a structured refusal naming the exact next step -- there is no bypass, the approval is deliberate.

get_implementation_prompt

Fetch agent-specific mission and context. Call immediately after receiving the thin prompt from spawn_job -- your first action. The response carries your role instructions (agent_identity) and agent_profile (role, model and effort hints) -- act from them; do not look for installed agent files. Idempotent. Pass protocol_etag from a prior fetch to skip the unchanged identity+protocol block (response sets protocol_unchanged=true). Truncation recovery: pass section=<name from protocol_toc> to refetch ONE small section of full_protocol.

get_job_mission

List the conversations waiting on YOU -- threads where you hold the turn, plus anything addressed to everyone. Pass wait_seconds to WAIT for the next one instead of returning immediately: the call comes back the moment something arrives for you, or empty if nothing does, and costs nothing while it waits. Waiting beats sleeping and re-asking. Chat surfaces that cannot hold a call open should leave wait_seconds at 0 and ask again on their own schedule.

get_my_turn

Who on this thread is still there. Returns each participant with when they were last seen and a coarse state -- active, quiet, gone, or unknown for someone who has joined but not yet acted. Use it before deciding whether to keep waiting on an agent, reassign its work, or escalate past an orchestrator that has gone dark.

get_participant_liveness

Read the current roadmap for the DEFAULT product, or an explicit product_id (read-only). Items are sorted by sort_order; returns roadmap=null + items=[] when none exists yet. Call this before re-ranking to see the existing order and any terminal-state items. Defaults to your default product; pass product_id to read a specific product's roadmap.

get_roadmap

Fetch context for the orchestrator to CREATE a mission plan (near the start of staging, or during implementation to refresh context). Returns project description (user requirements), prioritized context fields, and agent_templates for discovering specialists. Orchestrator-only; analyzes this INPUT, does NOT execute work.

get_staging_instructions

Read a thread's message timeline, oldest-first. READ-ONLY by default (does NOT acknowledge; pass mark_read=true to do so). See tail/after_message_id/since for polling and as_participant for the persistent per-participant read cursor.

get_thread_history

Retrieve a product's vision document with extraction instructions. Call WITHOUT chunk to get metadata (total_chunks, extraction_instructions). Then fetch chunk=1 through chunk=total_chunks -- these reads are independent and side-effect free, so request them in PARALLEL, in any order. Read ALL chunks before calling update_product_context.

get_vision_document

Monitor workflow progress across all project agents. Returns active/completed/blocked/closed/silent/decommissioned/pending agent counts and progress_percent (0-100). Note: progress_percent is an agent-count ratio (completed/total agents), NOT a measure of work done. Use exclude_job_id to omit the calling orchestrator's own job from counts.

get_workflow_status

Check MCP server health status.

health_check

Join a message-board thread by its thread_id, declaring/claiming your agent_id. Collision-safe (re-joining is a no-op). Registers you in the participant directory so broadcast posts reach you.

join_thread

Release the implementation gate for a staged project: the second of the two human-authorized doors that stamp implementation_launched_at (the first is the dashboard's Implement button). Reachable from any MCP client; admission follows the tenant's Headless setting (off by default): when on, your harness's own permission prompt for this call counts as the approval, so a bypass flag means nobody was asked. Idempotent (a second call returns already_launched=true); not offered to a platform-spawned worker, so a worker cannot self-unlock. Launching also makes an inactive project active (project_active in the response confirms it; a project in another status is left alone and next_action says what to do). An optional mission is written through update_project_mission before the gate is stamped.

launch_implementation

Link two or more existing projects to run one after another, under one shared goal. Say which projects, in the order they should run. Your session then drives them: work the first to completion, and the next becomes ready automatically -- check get_workflow_status(project_id) and its ready_to_advance field to see when. Use unlink_projects to abandon the group part-way. Projects must already exist and be unfinished; create them first.

link_projects

List and search projects for your default product (pass product_id for another). The default view shows active-lifecycle projects only; pass include_completed=true or an explicit status for more. query finds a project by name, serial or a word from its description; mode=triage|planning|audit|forensic sets the detail level (cheapest first). Every response carries counts for the whole board and counts.matched for your filters; a response cut by limit (default 50, max 500) says so and carries truncation.next_cursor to walk the rest. Details and read-vs-write routing: get_giljo_guide.

list_projects

List tasks for your default product (pass product_id for another). mode='index' (leanest), 'summary' (default) or 'full'. query finds a task by a word in its title, description or alias; task_type filters 'TSK' (ordinary) or 'HND' (session handovers). Bounded: a cut response says so (truncated + truncation) and carries truncation.next_cursor to walk the rest; counts sizes the whole board, your match and this page. Details: get_giljo_guide.

list_tasks

Find chats. Newest first. Pass query to search by chat id, subject, participant or message text; pass any of status / owner / product_id / project_id to filter; pass nothing to list them all. Filters and query combine.

list_threads

Post a message to a thread (append-only): the agent-to-agent messaging tool. from_agent is required (or as_user=true to post in the human user's voice). Broadcasts by default; to_participant direct-messages one participant, pass_baton_to hands the turn with the post, set_status resolves or closes the thread. Name only personas that have join_thread'ed: the baton is refused for an unregistered id, and a DM to a never-joined id is read by nobody. A post reopens a resolved thread.

post_to_thread

Turns a task into a project in your own private Giljo HQ workspace, for a task that turned out to be bigger than one step. Creates a project from the task on the task's own product, moves its subtasks and any roadmap card to the project (same roadmap position), and DELETES the task: its task_id no longer resolves, so carry the returned project_id instead. The new project is inactive and untyped; give it a type with update_project, and the user activates it from the dashboard. Only the task's creator or an admin may promote it, and a handover task cannot be promoted. Tenant-scoped. No outside service is contacted.

promote_task_to_project

Propose new text for one agent template's instructions or one product's orchestrator prompt additions. Nothing changes until the user presses Apply in Tools > Agents. Each target holds one waiting proposal; a new one replaces it. Relay the response's tell_the_user line to the user.

propose_template_change

Take items off the roadmap. Removes only the roadmap entry, never the project or task itself; an item that is not on the roadmap is a no-op. Defaults to your default product; pass product_id for a specific one.

remove_roadmap_items

Report incremental progress with TODO items. Backend auto-calculates percent and step counts. Also auto-wakes idle/sleeping/blocked agents back to 'working' status.

report_progress

Request a user approval before continuing (HITL gate: closeout with deferred findings, an ambiguous decision). Orchestrator jobs only -- a worker call is rejected with ORCHESTRATOR_ONLY_APPROVAL; escalate via post_to_thread instead. See get_giljo_guide for how the dashboard surfaces and clears this gate.

request_approval

Set a finished job that an action-required message put on hold back to working, so it can act on that message. Only works while the job is on hold. Changes only the job's status in your own Giljo HQ workspace; nothing is deleted.

resume_job

Save the roadmap -- the ranked list of what to build next. YOU do the ranking; the server only validates and stores it. Send the items you want on the board and they are written, replacing any earlier entry for the same project or task; see items for the shape. To take an item off the board call remove_roadmap_items. Defaults to your default product; pass product_id for a specific one.

save_roadmap

Search the 360 memory (closeouts/handovers) by keyword to answer 'have we solved X before?'. Matches summary, key_outcomes, decisions_made, project_name, tags, and git_commits (a closeout's commit messages -- e.g. 'when did we fix the redirect bug'); optional tag narrows to one controlled-vocabulary value. Tenant-scoped (never pass tenant_key); defaults to your default product, pass product_id to search a specific product instead. Returns relevance-ranked headlines, capped at limit. Distinct from get_context(memory_360) (recency, not search) and list_threads(query=...) (Hub chat, not memory).

search_memory

Set agent resting/blocked status: 'blocked' (needs human help), 'idle' (monitoring), or 'sleeping' (periodic check-in). All three auto-wake to 'working' on report_progress(). Server-locked for the orchestrator during staging (403 STAGING_LOCK) -- use report_progress instead. Spawned non-orchestrator agents bypass the lock.

set_agent_status

Set who acts next on a chat. Give an agent_id, a user_id, 'all' (anyone may act) or 'none' (CLEARS it -- nobody is waiting). Whoever you name finds it via get_my_turn. NOTE the difference from post_to_thread's pass_baton_to parameter: there, 'none' means LEAVE the current actor alone. Here it CLEARS them. Clearing is the one thing only this tool can do. The agent you name must already have join_thread'ed this chat -- the baton is refused for an id not registered on it.

set_next_actor

First-time setup: installs the /giljo command/skill and writes the Giljo HQ marker block (primer and product binding) into your harness file (CLAUDE.md / AGENTS.md); following the returned instructions replaces earlier Giljo HQ skills and the Giljo-managed block, nothing outside it. Run once after connecting; re-run when skills are outdated. Pass platform naming your own tool ('claude_code'|'codex_cli'|'opencode'|'generic'): the wrong one installs skills where your tool never reads them. With no home directory (web sandbox, chat) pass harness to get the primer inline. Pass product_id to bind this repository to a product so later calls never hit PRODUCT_AMBIGUOUS; omit it on a tenant with zero or several products. No agent files are installed: each spawned agent gets its profile from get_job_mission's agent_profile. Every tool response carries _meta.skills_version; when it is ahead of what is installed, tell the user and offer to re-run this tool. Local skill files are only rewritten after the user agrees.

giljo_setup

Create a specialist agent job (orchestrator only, during staging). Returns job_id and a thin prompt; the agent calls get_job_mission to fetch its full mission. In multi_terminal mode the prompt is a dashboard Copy pointer unless inline_seed=true.

spawn_job

Prepares a project in your own private Giljo HQ workspace and returns its staging plan; an inactive project becomes active, a closed one is refused. Staging always ends at a human approval gate: nothing is implemented until the user approves with the dashboard's Implement button or launch_implementation, and approving also makes an inactive project active. Ask the user which mode to use (subagent or multi_terminal); without one and without an account default the call is refused with EXECUTION_MODE_REQUIRED. An optional mission is written through update_project_mission. To undo staging use unstage_project. No outside service is contacted.

stage_project

Abandon a linked group of projects part-way: the ones that have not run yet are released and the group stops. Projects already finished stay finished. Use this when the plan changes mid-run.

unlink_projects

Undoes staging in your own private Giljo HQ workspace, any time before implementation starts. Clears the project's staging state and its mission, and retires an orchestrator that had already started on it for a fresh one. This also starts staging over: call stage_project again afterwards. Refused once implementation has started, and while the orchestrator is actively running. To abandon a project instead, call update_project with status 'cancelled'. It does not approve or launch anything. No outside service is contacted.

unstage_project

Persist an agent's mission/execution plan. Orchestrator-only, called during staging so a fresh-session orchestrator can retrieve it later via get_job_mission() during implementation.

update_job_mission

Write structured product fields extracted from vision-document analysis. Merge-write: only the fields you pass change, so it is safe to call in stages; set emit_completion=true on the last call. Every response reports vision_analysis_complete, missing_for_completion and fields_skipped.

update_product_context

Update a project's metadata (name, description, status, project_type, series_number, suffix, successor_project_id); only the fields you pass change. status='completed' on a solo project runs the full archive lifecycle (what the dashboard's Archive button does) and needs a closeout first (see force). status='superseded' requires successor_project_id in the same call, else SUPERSEDE_REQUIRES_SUCCESSOR. Find the project with list_projects first.

update_project

Save the orchestrator's mission plan (the execution OUTPUT), distinct from Project.description (the user's INPUT requirements). Orchestrator-only, called after creating the execution strategy during staging. Triggers a WebSocket UI update.

update_project_mission