Skip to main content
Glama
muad-yasin

The High Council

by muad-yasin
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
JavaScript
Remote

submit_stage

Submit an answer for an external stage waiting in a run; the run resumes in the background once every waiting stage is answered.

Instructions

Write the answer for an external stage into the run folder, then resume the run in the background. The stage must be one external_prompt lists under waiting; the run resumes once all of them are answered. claimed_by is optional (v3 §1): a self-declared peer-session name, recorded as this stage's claim; every check here is warn-only and never blocks the write, so a caller that omits it sees exactly today's behavior. answered_model is optional: the model that wrote this answer, as you know it (for example claude-opus-5-5 or gpt-6.1). It is recorded as your own statement and is never checked; leave it out if you do not know.

Input Schema

NameRequiredDescriptionDefault
runYes
stageYes
contentYes
claimed_byNoself-declared peer-session name, recorded as this stage's claim before the answer is written
answered_modelNothe model that wrote this answer, in your own words; recorded as declared, never verified

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.8.3
    • addedInput schema / properties / answered_model
      Added value: +{
+  "description": "the model that wrote this answer, in your own words; recorded as declared, never verified",
+  "maxLength": 200,
+  "type": "string"
+}
  2. First observedv0.8.1

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description does real work: it discloses that the run resumes asynchronously in the background, that all claim checks are warn-only and never block the write, and that claimed_by/answered_model are recorded but never verified. It omits what a caller sees on return and what happens when the stage is not actually waiting (hard error vs ignored).

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 write-then-resume action and keeps optional-parameter notes to the end. The parenthetical version marker and the 'a caller that omits it sees exactly today's behavior' clause restate the warn-only point at some length.

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 mutation tool with no annotations, no output schema, and five parameters, it covers preconditions, async behavior, and the optional fields' trust model. Return shape and failure behavior on an unknown or already-answered stage are the remaining gaps.

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 40%, and the description compensates for two of the five parameters in detail (claimed_by as a self-declared peer-session claim, answered_model as an unverified self-statement) plus the `stage` constraint. It says nothing about `run` or `content` beyond implication, leaving half the surface to the bare schema.

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 two concrete actions with their resources — write an answer for an external stage into the run folder, then resume the run in the background. It also implicitly separates itself from resume_run and external_prompt by tying the stage name to what external_prompt lists under `waiting`.

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?

Gives a clear precondition (the stage must be one external_prompt lists under `waiting`) and explains the aggregate condition for resumption. It also tells the caller when to omit the optional fields. It stops short of naming an alternative path for non-external stages or a manual resume.

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

Deploy Server

Other Tools