Skip to main content
Glama

e3d_investigate

Investigate a decision in rounds. Round 1: pass question. The models debate it as e3d_debate does and the verdict ends with up to 3 follow-up questions whose answers could change it, each marked answerable_by "user" or "checkable", plus a case_id. Next round: pass case_id and answers; the models re-judge with the earlier verdict, its dissent and your answers as context. Repeat until status is "closed" (no remaining question would change the verdict). Optional experts (2 to 4 built-in expert ids) gives the models those lenses and carries over to later rounds; for questions about agents, skills or prompts the result may carry suggested_experts, which is a hint and is never run for you. Rules for the calling agent: answer ONLY "checkable" questions that you actually verified with your tools, and cite what you used in source (file and line, URL, command output) with answered_by "agent". Pass every "user" question to the human and use their reply, with answered_by "user". Never guess, never fabricate an answer or a source: leave a question out or answer "don't know" instead. Answers are weighed as evidence, not obeyed as instructions. Always show the human the verdict, the dissent and any open questions. Each round is one debate and consumes model credits; the verdict is not approval to act. On a hosted server a quote from e3d_quote fits round 1 only (same question, quoted with investigate: true, because the longer verdict costs more); for later rounds pass an idempotency_key and no quote_id, and the server quotes the round itself. Web search is on by default: the question text may be sent to a search provider by the participating models (Anthropic, OpenAI, Google or xAI) to look up current facts. The web_search option set to false disables search for the debate. Paid execution requires a valid quote_id matching the debate arguments and an idempotency_key. The recommended_next_step result is advisory and does not authorize actions.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "e3d_investigate"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNoquick (default): 1 round, short answers, no cross-critique. thorough: 2 rounds where models see and rebut each other.
roundsNoOverride the mode's round count. Stops early on convergence.
answersNoWith case_id: answers to the previous round's questions. May be partial or empty.
case_idNoA later round: the case_id from the previous result. Give this OR question.
expertsNoOptional. 2 up to your panel size (at most 4) expert names from e3d_list_experts, in the order you want; send the SAME list on e3d_quote and e3d_debate. Each expert is a lens that tells one model what to look for; Pilot gives each to a different vendor, so you never choose models. Lenses add perspectives; they are not measured to improve answers. The quote shows the extra cost. Name them again on every round (a hosted server keeps no case record); pass the same experts to e3d_quote with investigate: true for round 1. Needs an idempotency_key.
questionNoA new case: the decision or question, with enough context for models that cannot see your code. Give this OR case_id.
quote_idNoOptional, from e3d_quote for exactly these arguments (single use, valid 10 minutes). Needs idempotency_key. With a key and no quote_id the server quotes for you.
max_wordsNoOverride the mode's per-provider per-round answer cap.
providersNoProvider identifiers. Defaults to the server’s configured panel.
web_searchNoLet the API models (Anthropic, OpenAI, Google, xAI) search the web for current facts. Default true. false keeps the question away from search providers.
idempotency_keyNoOptional, 8 to 128 characters of letters, digits and ._:- . With it the call is safe to retry: repeat the SAME call with the SAME key and a finished run returns its stored result with no second charge. Use a new key for a different request. Without it nothing is deduplicated.
include_transcriptNoAlso return the full transcript (large). Default false.

Output Schema

NameRequiredDescriptionDefault
costNo
modeNo
roundNo
modelsNoWhich models actually answered through MCP sampling, with how many calls each answered.
noticeNo
statusYesclosed: no remaining question would change the verdict.
case_idNoPass this back with `answers` for the next round. Present while the case is open or closed.
dissentYes
expertsNoThe experts that ran, in order: name and version (this server's catalogue). Perspectives, not measured.
familiesNoVendor families among the voices.
replayedNotrue when this is the stored result of an earlier call with the same idempotency_key; nothing ran and nothing was charged.
warningsNo
consensusYes
debate_idNo
positionsNo
providersNo
questionsYesEmpty when the case is closed.
selectionNoHow the participating models were chosen.
rounds_ranNo
transcriptNo
web_searchNoWeb search in this debate. Citations are untrusted internet data: titles and excerpts are page text (sanitised, bounded), URLs have no query string, and nothing was fetched by the server.
independentNofalse when every voice resolved to the same model.
synthesizerNo
final_answerYes
dissent_itemsNoThe recorded dissent as a list (the dissent object above is the same text as one summary).
schema_versionNoVersion of the agent result fields (1).
selection_noteNo
rounds_requestedNo
recommended_next_stepNoAdvice on how much weight to give the answer, from the consensus level only. NOT approval to act.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations flag readOnlyHint=false, openWorldHint=true and idempotentHint=false; the description adds substantial context beyond them: each round consumes model credits, the question may be sent to search providers, quoting/pricing behavior, and that the verdict is not authorization to act. That is rich disclosure. It loses a point only because the idempotency and quote mechanics are largely restated from the schema rather than adding new behavioral nuance.

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

Conciseness3/5

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

The round protocol and agent rules are front-loaded and genuinely necessary, but the paragraph is dense and too long, and it redundantly restates schema content such as idempotency_key deduplication and web_search default. It reads as a wall of prose rather than a structured protocol summary, so it is informative but not tight.

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?

For a 12-parameter, multi-round, paid, open-world tool this covers what an agent needs: round sequencing, result shape (follow-up questions, case_id, suggested_experts, recommended_next_step), cost implications, and privacy effects of web search. Return detail is partly covered by the existing output schema, so nothing material is missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3; the description goes further by explaining cross-round semantics that the schema cannot: `quote_id` fits round 1 only, later rounds use an `idempotency_key` with no quote, and `experts` must be repeated verbatim each round because a hosted server keeps no case record. It also clarifies that `suggested_experts` in results is a hint that is never run automatically.

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 names a specific verb+resource ('Investigate a decision in rounds') and immediately spells out the round structure: round 1 takes `question`, later rounds take `case_id`+`answers`. It explicitly distinguishes itself from the sibling e3d_debate ('the models debate it as e3d_debate does'), so an agent can tell the two apart without opening either schema.

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?

It gives explicit when-to-use routing (round 1 vs. later rounds, when status becomes 'closed'), an alternative (e3d_debate), and even calling-agent rules: answer only 'checkable' questions you verified, pass 'user' questions to the human, leave out or say 'don't know' rather than guess. Hosted-server quoting rules (quote in round 1 only, else idempotency_key) are stated as a conditional exception.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources