Skip to main content
Glama

The interview of a model: who answers which input and how far

interview

Tracks ownership, progress, and corrections for model elicitation, letting agents claim inputs, resume stopped runs, audit answers, and accept or reopen steps.

Instructions

Track the interview of a model: ownership, progress, review and corrections.

progress names every input key with its state, owner, answered parts and publication; call it before handing a shock to an agent. claim gives one key to one agent; a live claim of another agent refuses a second writer. release drops the caller's claim. restart resumes an agent whose run stopped — a network error, a timeout, a crashed client: it renews that agent's claim and returns the first missing part, so the same agent continues where the saved parts end and nothing is asked twice. audit lists the advisory findings of one published answer or of every one. accept records that the warnings were reviewed, with the reason; reopen asks named parts again, keeps the old answer as a version and makes the key missing until it is complete again. history lists the versions of one answer and journal the last events of the interview.

This tool never writes an answer: the numbers come only through elicit. The orchestrating agent owns the process: it hands one shock to one subagent, reads the warnings and either accepts the answer or reopens the steps they name.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>",
      "as_of": "<as_of>",
      "model_id": "<model_id>"
    },
    "name": "interview"
  }
}

Input Schema

NameRequiredDescriptionDefault
keyNoThe input key, one shock or market: named by every action that touches one answer, left out by progress and by the whole-model audit.
agentNoThe name of the answering agent: it owns the claim and is written to the journal; required by claim.
as_ofYesThe calculation date, YYYY-MM-DD: the interview of this date.
limitNoHow many last journal events journal returns, 50 by default.
stepsNoThe parts to ask again, by step id from the question; required by reopen and refused when a step is unknown.
actionYesprogress, claim, release, restart, audit, accept, reopen, history or journal: the state of an elicitation, not its answers.
reasonNoWhy a published answer is accepted or reopened: written to the journal and to the accepted record.
minutesNoHow many minutes a claim stays alive without renewal, 45 by default; a stopped agent does not block its shock forever.
model_idYesThe macro model that asks the questions, for example expert.elicited.rw; model(kind="catalog") lists the installed ones.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only say the tool mutates, is non-idempotent, non-destructive and closed-world; the description supplies the actual semantics: a live claim by another agent refuses a second writer, release drops only the caller's claim, restart renews the claim and returns the first missing part so nothing is asked twice, reopen versions the old answer and makes the key missing again. These are exactly the consequences an agent needs before mutating shared state.

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?

Purpose is front-loaded in one line, followed by per-action sentences in backticks and a closing paragraph on the orchestration model; every sentence carries information. It is dense but not padded, though the backtick-heavy formatting and the many actions packed into one paragraph make skimming harder than a short list would.

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 nine-parameter, nine-action state machine this covers all actions, the claim lifecycle, versioning on reopen, and even what restart returns, despite an output schema existing. Nothing an agent needs in order to pick an action and call it correctly is left out.

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

Parameters3/5

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

Schema coverage is 100% and the field descriptions already state which actions require key, agent, steps and reason, plus the 45-minute claim lifetime. The description reinforces the conceptual role of key (one shock or market) and agent (owner of the claim) but adds little that the schema does not already say, so the baseline 3 applies.

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 opening line names a specific verb and resource (track the interview of a model) and enumerates the facets: ownership, progress, review and corrections. It also draws a hard boundary against the sibling that produces answers: "This tool never writes an answer: the numbers come only through ``elicit``." An agent can tell what this tool is and is not without opening the schema.

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

Usage Guidelines4/5

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

Each action carries an explicit use condition: progress "before handing a shock to an agent", restart for an agent whose run stopped by network error, timeout or crashed client, accept vs reopen for warnings that were or were not satisfactory. The alternative (elicit) is named for the write path. What is missing is a consolidated when-not rule, e.g. that audit should not be used before publication or that release is unnecessary after the claim expires.

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