Skip to main content
Glama

Start a peer consultation

consult_start

Start a background consultation with one or more AI agents, choosing explore, review, or debate mode to get independent opinions; returns a job ID immediately for polling results.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It discloses that work runs asynchronously, the consultant starts in an empty working directory and is not told the repo location, model/permissions/timeouts are fixed, same-vendor calls are annotated with a caveat, and prediction is never sent to the consultant and cannot be rewritten afterward.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long, but the tool is genuinely complex with nested parameters, three modes, fan-out, model suffixes, and privacy behavior. The structure is front-loaded with the key contract, then organized by parameter, and nearly every sentence carries operational value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high parameter complexity, no output schema, and no annotations, the description is remarkably complete. It covers return values, how to poll via consult_get, mode preconditions, unavailable targets, same-vendor caveats, prediction privacy, and environment constraints that would otherwise be invisible to an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the parameter documentation burden falls entirely on the description. It compensates thoroughly: target/targets semantics, followup_to restrictions, caller/caller_model intent, prediction shape and immutability, and mode-specific requirements for context.proposal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb and resource: 'Start a consultation with another agent (or several, via targets)' and states the immediate return contract (job_id/group_id, background execution). It clearly distinguishes consult_start from its siblings by framing it as the initiation step and explicitly referencing consult_get and consult_record for follow-up actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance for each mode: explore requires empty proposal, review requires proposal, debate requires both proposal and counterpoints. It also names alternatives and exclusions: targets is mutually exclusive with target, follow-ups never fan out, unavailable consultants are refused up front and should not be retried, and a model suffix should only be passed when the user asked for one.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.