Skip to main content
Glama
WatermelonBros

Reado

by WatermelonBros
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

session_done

Signals that the request is finished, blocked, or awaiting user input so Reado can notify someone who has stepped away. Call only when stopping to wait, not after each step.

Instructions

Call this when your next act is to wait for the user — the request is finished, you are blocked, or you need an answer. NOT after a command returns or a step completes: if you will do anything else before stopping, it is too early. Reado alerts a user who has walked away, so a premature call fetches them back for nothing. Answers an acknowledgement.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusNoHow the request ended. Defaults to done.
summaryNoOne line on what happened; it becomes the notification's text.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.32.1
    • addedInput schema / properties / status / description
      Added value: +"How the request ended. Defaults to done."
    • addedInput schema / properties / status / enum
      Added value: +[
+  "done",
+  "blocked",
+  "failed"
+]
    • addedInput schema / properties / summary / description
      Added value: +"One line on what happened; it becomes the notification's text."
  2. First observedv1.32.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations establish this is a non-read-only, non-idempotent action, and the description adds a real behavioral consequence not in the annotations: Reado alerts a user who has walked away, so a premature call 'fetches them back for nothing.' That side effect is the key operational trait. It does not, however, describe any result/confirmation behavior, and the trailing 'Answers an acknowledgement.' is opaque.

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?

The critical trigger and its exclusion are front-loaded and the sentence count is small. Minor waste and confusion come from the garbled 'Reado' reference and the unfinished 'Answers an acknowledgement.' fragment.

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?

With no output schema and zero required parameters, the description's main job is to nail the invocation trigger, which it does thoroughly, including the anti-pattern case. It is nearly complete; only the vague closing fragment leaves a small gap.

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%: both parameters (status enum, summary line) are fully documented in the schema, including the enum values and what the summary becomes. The description adds nothing beyond that, so the baseline 3 applies.

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 clearly states the tool signals the end of the turn ('your next act is to wait for the user'). It distinguishes the session-level trigger from intermediate steps, but never names or differentiates itself from the closely related task_done/task_fail/task_block siblings, which an agent will have to disambiguate on its own.

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 explicit when-to-call conditions (finished, blocked, need an answer) and an explicit when-NOT ('NOT after a command returns or a step completes... if you will do anything else before stopping, it is too early'), plus the rationale that a premature call needlessly summons the user. This is about as complete as usage guidance gets.

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