Aetherya

Approve, answer, cancel or retry a planned study

aetherya_confirm_study

Respond to a plan from aetherya_plan_study. Use action 'confirm' with accept_sessions to approve the quoted cost and start the run — this is the point at which simulation sessions are spent, so check with the user first. Use 'answer' to reply to the clarifying questions (answers with the option ids the user picked, or answer for one free-text reply), 'cancel' to abandon the plan, or 'retry' after a failure. After confirming, the run continues and returns its decision brief when it finishes.

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": {
      "autopilot_id": "<autopilot_id>",
      "action": "<action>"
    },
    "name": "aetherya_confirm_study"
  }
}

Input Schema

Name	Required	Description
`action`	Yes	'confirm' accepts the quoted cost and starts the run (requires accept_sessions). 'answer' replies to the clarifying questions (requires answers or answer). 'cancel' abandons the plan. 'retry' re-runs a failed plan.
`answer`	No	For 'answer': a free-text reply to the (first) question asked. Prefer answers when the plan lists questions.
`answers`	No	For 'answer': one entry per question from the plan's questions, with the optionId the user picked or their own text. A question left out keeps its default. Only relay what the user said.
`autopilot_id`	Yes	The autopilotId from aetherya_plan_study.
`accept_sessions`	No	Required for 'confirm': the exact sessions figure from the plan's estimate. Never invent it — a mismatch is rejected and re-quoted.
`max_wait_seconds`	No	How long to wait inline after confirming before handing back an id. Defaults to 45.

Output Schema

Name	Required	Description
`id`	Yes
`kind`	Yes
`legs`	No
`next`	Yes
`step`	Yes
`brief`	No
`error`	No
`source`	Yes
`status`	Yes
`audience`	No
`estimate`	No
`progress`	Yes
`question`	No
`research`	No
`questions`	No
`stepLabel`	Yes
`autopilotId`	Yes
`requiredSessions`	No	Set only on a re-quote — confirm this figure instead.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the irreversible cost moment (sessions spent on confirm), that the run continues asynchronously and returns a decision brief, and that a mismatched accept_sessions is rejected and re-quoted. Nothing here contradicts readOnlyHint=false / destructiveHint=false.

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-loads the entry point and the most dangerous action first, then walks through the remaining actions in one dense but waste-free paragraph; slightly long, but each clause carries operational information.

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?

An output schema exists so return values need not be explained; the description still covers the follow-up behavior, the cost confirmation gate, failure handling, and the relationship to aetherya_plan_study, leaving no obvious gap for an agent to call this correctly.

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 already 100%, so baseline is 3, but the description adds genuine meaning: accept_sessions must match the plan's estimate exactly and must never be invented, and 'answer' can be either option ids or a free-text reply.

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+resource ('Respond to a plan from aetherya_plan_study') and enumerates the four supported actions with distinct semantics, which cleanly separates it from siblings like aetherya_run_study, aetherya_cancel, and aetherya_plan_study.

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?

Gives explicit when-to-use for each action ('answer' for clarifying questions, 'cancel' to abandon, 'retry' after a failure) and an explicit when-not guardrail: check with the user before 'confirm' because sessions are spent at that point.

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

All Aetherya tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?