MacroStress

Overview Schema Source Related Servers Discussions Admin

The questions of a model and the answers the agent writes

elicit

Collects an agent's macro-model input judgements one small question at a time, saving each answer so interrupted interviews resume at the first missing step.

Instructions

Answer a macro model's questions in small resumable steps.

Start with next and model_id/as_of. It gives one small question, its schema and answer_call. Copy answer_call with your answer object as payload to answer; the result saves it and gives the next question. Continue until complete=true. Each response step asks nine numbers, not a full shock table. Partial answers survive a restart and never count as a completed input. Never substitute placeholders or ask the human for numbers. next resumes the first missing step.

A model that declares inputs is estimated from the agent's own answers, not from the series: list names every input key on the date and status repeats the summary. Full question/write operations belong to model(kind="inputs"), not this interview. The agent is the expert: the numbers are its own judgements, not the human's and not the fixtures of the tests. When nothing is missing, build the version: model(kind="macro", action="estimate", model_id=..., as_of=...) starts a job, and jobs(action="wait", id=...) holds until it ends. The same actions are kind="inputs" of the model tool.

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>"
    },
    "name": "elicit"
  }
}

Input Schema

Name	Required	Description
`key`	No	The input key question and write read: one of the keys list names.
`agent`	No	The name of the answering agent: it is written to the journal and to the claim of the key, so progress names its owner.
`as_of`	No	The calculation date, YYYY-MM-DD: required for next and list; answer reads the date from its ticket.
`action`	Yes	Use next to start or resume one small question; answer saves its payload using the returned ticket and gives the next question. list and status only report completed inputs. Do not request full question/write here.
`ticket`	No	Copy the ticket from next's answer_call unchanged; it addresses the model, date, shock and exact step without repeating those fields.
`payload`	No	The answer object write checks and stores, as the question's schema asks; the object itself, not a string of JSON.
`model_id`	No	The macro model that asks the questions; every installed model that does when omitted and one of them when several.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.1.0Nov 9, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=false and the absence of destructive/open-world behavior, so the description carries most of the load and does so well: responses are chunked (nine numbers per step, not a full shock table), partial answers survive restart and never count as a completed input, and the ticket addresses model/date/shock/step without repeating fields. What it does not address is what happens if a step is answered twice or with an invalid payload — an idempotentHint=false write path whose conflict behavior stays unstated.

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 first sentence and the next/answer loop are correctly front-loaded, and the procedural sentences earn their place. The middle section drifts into exhortation ("The agent is the expert: the numbers are its own judgements, not the human's and not the fixtures of the tests") and the closing line restates that the same actions exist under model kind=\"inputs\", which is redundant with the earlier sibling reference.

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

Completeness4/5

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

For a stateful, multi-step tool with seven parameters, an output schema, and rich annotations, the description covers the loop, resumption semantics, and the handoff to estimate/jobs — enough to drive it correctly end to end. Gaps remain around failure and retry behavior on the answer path and around what status/list return, though the output schema likely carries the latter.

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 description coverage is 100% and each of the seven parameters already carries a detailed inline description, so the baseline is 3. The description adds workflow meaning the schema cannot — that ticket must be copied unchanged from answer_call, that as_of is needed for next/list while answer reads the date from its ticket, and that model_id may be omitted to cover all installed models — but it never touches payload contents or key semantics beyond pointing at list.

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

Purpose4/5

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

The description names a specific activity — answering a macro model's questions one small step at a time via a next/answer loop — and enumerates the actions it supports (next, answer, list, status). It also explicitly walls off adjacent behavior ("Full question/write operations belong to model(kind=\"inputs\"), not this interview"), so an agent can separate it from the model sibling. It falls short of 5 only because the framing is delivered in circuitous, literary prose before the plain statement of purpose lands.

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 an ordered procedure with concrete transitions: start with next plus model_id/as_of, copy answer_call into answer with the payload, repeat until complete=true, and next resumes the first missing step. It states exclusions (never substitute placeholders, never ask the human for numbers, don't request full question/write here) and names the alternative tools to use at the end (model kind=\"macro\" action=\"estimate\" then jobs action=\"wait\").

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

Deploy Server