Metis

Official

Overview Schema Source Related Servers Discussions Admin

Relay a worker's answer to a whisper

answer_whisper

Relay a worker's own response to a whisper with their consent, so confirmed or corrected accounts can enter review as evidence while other answers store nothing.

Instructions

Relay a worker's own answer to a whisper, with the consent they stated. Use it only with the choice and words of the worker the whisper is addressed to, never with your own judgement. To start a capture, use submit_observation; to dispute a stored fragment, use contest_fragment. A fragment is stored only for confirm, or correct with the worker's corrected_text, given with consent granted: it enters the Evidence layer and reaches agents only after a quorum of Mission Group reviewers promotes it. Any other answer is recorded and stores nothing. Every answer, defer included, closes the whisper, and a second answer or one from anyone but its addressee is refused.

Input Schema

TableJSON Schema

Name	Required	Description
`consent`	Yes	The worker's own decision on keeping their account: granted keeps it, declined keeps nothing. Relay what the worker said.
`response`	Yes	The worker's answer: confirm (the candidate is right), correct (right with the changes in corrected_text), dismiss (not a real practice), or defer (the worker will not answer now). Each closes the whisper.
`whisper_id`	Yes	The whisper's id, from submit_observation or list_pending_whispers.
`answered_by`	Yes	The worker who answered: the person the whisper is addressed to.
`corrected_text`	No	Required with response correct: the worker's corrected account in their own words.

Output Schema

TableJSON Schema

Name	Required	Description
`note`	Yes	What happens next.
`stored`	Yes	True when the answer stored a fragment.
`consent`	No	The worker's recorded consent.
`fragment_id`	No	The stored fragment.
`authority_layer`	No	evidence: visible to agents only after reviewers promote it.
`validation_state`	No	Its validation state.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.6Oct 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only mark this as non-read-only, non-destructive, non-idempotent. The description adds substantial beyond that: only 'confirm' or 'correct'+corrected_text stores a fragment, it enters an Evidence layer, and reaches agents only after Mission Group quorum promotion; every answer closes the whisper; a second answer is refused. This is exactly the kind of downstream consequence an agent cannot infer from annotations.

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?

Front-loaded with the core action and constraint, then branches to alternatives and persistence behavior. Dense but every clause carries operational meaning; slight packing of multiple ideas into the final sentence costs a point.

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?

Covers the consent semantics, persistence rules, the quorum promotion pipeline, terminal nature of the call, and rejection behavior. With 5 params (4 required, 2 enums) and a mutation tool, this gives an agent everything needed to invoke correctly; the output schema handles the return shape.

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 clarifying that 'defer is included' in the set that closes the whisper and that 'correct' requires the worker's own corrected_text — reinforcing enum semantics in a way that matters when the agent is relaying a worker's answer verbatim.

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?

States a specific verb (relay) and resource (a worker's own answer to a whisper), then explicitly routes to siblings: submit_observation for starting a capture and contest_fragment for disputes. An agent can distinguish this from any other tool in the sibling list without opening a 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?

Explicit when-to-use ('only with the choice and words of the worker the whisper is addressed to, never with your own judgement'), when-not (any answer from anyone but the addressee is refused), and alternatives (submit_observation, contest_fragment). This is the strongest level of guidance.

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

Deploy Server