Start a consultation with another agent (or several, via targets). Returns a job_id (or a group_id for several) immediately; the work runs in the background.

target: which consultant to ask. This machine can reach: (none -- no consultant CLI is installed). The everyday names work too: gpt/chatgpt/openai, claude/anthropic, gemini/agy/google. A consultant that is not in that list is refused up front, so do not retry it -- say which ones are available instead. Consulting your own CLI is allowed but is a fresh-context check rather than an independent opinion, and the result says so. targets: ask up to 3 consultants the same question at once (mutually exclusive with target, no duplicates). Every member gets the byte-identical brief and one group_id; poll it with consult_get({ group_id }). A follow-up (followup_to) always names one consultant -- fan-out is never available on a follow-up. A consultant may name the model to run it on as a suffix: "claude:claude-opus-5". What each consultant is allowed to run is set by the operator, and this server currently allows:

    Only pass a model when the user asked for one; a name outside the list is refused before the
    consultation starts, and a name matching two of them is refused rather than guessed.

caller: optional -- the CLI you are running in ("codex" / "claude-code" / "antigravity"), so the server can annotate a same-vendor consultation. caller_model: optional -- the model you are running on (e.g. "claude-opus-5"), self-declared and never checked. With it, a same-vendor caveat can say "same lineage, different model" and the record keeps who asked whom; it never changes which model the consultant runs. mode: explore - hand over objective/constraints/facts and withhold your own preferred solution, to get independent options, alternative problem framings and blind spots. context.proposal MUST be empty on round 1. review - hand over your current proposal AND the reasoning behind it, to get weaknesses, counterexamples, concrete improvements and the conditions under which it holds. context.proposal is required. debate - hand over the disputed point, your position (context.proposal), the other side's claims (context.counterpoints) and the extra evidence, to get what would change the judgement, how to test it, and which disagreements remain. Both are required.

The consultant starts in an empty working directory and is not told where your repository is: put every fact it needs into context.facts and paste the relevant passages into context.artifacts. Model, permissions, round count, timeout and size caps are fixed by this server and cannot be raised from a request.

prediction: optional -- { expected, worry }: the bottom line you expect back and, in one sentence, what you are most worried about. Stored with the consultation and NEVER sent to the consultant. It can only be written here, before the consultant runs, so that afterwards you cannot rewrite what you thought beforehand; consult_record takes the other half (reflection) once you have read the answer.

Fetch the state of a consultation. Pass wait_ms to block until it finishes (capped at 45000 ms, which stays under the request timeout MCP clients apply) instead of polling in a tight loop; a typical consultation takes one to five minutes, so expect to call this several times, and do something else in between. A completed job carries the structured answer; a failed one carries failure.kind (timeout, auth, usage_limit, model_unavailable, invalid_output, cli_error, spawn_error) — that is "no advice was obtained", which is different from advice that arrived with thin evidence (see quality.evidence_basis). Pass group_id instead of job_id to fetch a fan-out; wait_ms then waits for every consultant in it.

Stop a running consultation and kill the consultant process and everything it spawned. Pass group_id instead of job_id to stop every consultant in a fan-out.

Write your own verdict against one or more points of an answer, after you have checked them in the repository. Ids come from the result: findings are f1, f2 ..., unknowns u1 ..., next_checks c1 ... . verdict says what checking showed -- "confirmed" (it holds here), "not_applicable" (true in general, not for this codebase), "unverifiable" (cannot be settled with what you can reach), "unverified" (not checked yet, and say in effect why not). It does not say whether you adopted the point. effect is what it changed about your decision; note is the evidence you used. Recording the same id again replaces that entry. This server stores what you write and counts the verdicts; it never infers one, and never decides a consultation was worth it. The entry is saved beside the answer and the brief in ~/.severally/history, which is what makes the decision readable a month from now; the job is read back from that history, so a consultation from an earlier session can still be recorded against. Pass reflection to record what the answer added over what you already expected, when the consultation was started with a prediction. A prediction itself cannot be written here: it goes in consult_start, before the consultant runs, which is the only thing that makes it a prediction.

Render one consultation (chain_id) or one fan-out (group_id) as Markdown: the brief as it was sent, each consultant's answer as it came back, and the verdicts recorded against each point -- with the ones nobody checked marked as unchecked. Nothing is summarised across consultants and nothing is scored. The text is returned, not written: put it wherever the decision belongs in the repository (a decision record next to the code it is about), which is the only place a teammate will find it. Reads the on-disk history, so a consultation from an earlier session can still be exported.

Recent consultations from this session, newest first, with their status and one-line summary.