Skip to main content
Glama
WatermelonBros

Reado

by WatermelonBros
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

mascot_say

Sends one short line through Reado's on-screen mascot to alert a user away from their desk about a needed answer or just-landed update; refuses text over 280 characters.

Instructions

Say one line through Reado's mascot — the small companion in the corner of the user's screen. For the moment the user must know about while they are away from the desk: what you need from them, or what just landed. Not narration, not progress, not a running commentary: it interrupts a human, and a companion that chatters gets turned off. Use ask only when you are actually waiting for them. Text over 280 characters is refused, not truncated. Answers said: <text>.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
moodNoThe mascot's expression. Defaults to talk.
textYesOne line, at most 280 characters.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.32.1
    • addedInput schema / properties / mood / description
      Added value: +"The mascot's expression. Defaults to talk."
    • addedInput schema / properties / mood / enum
      Added value: +[
+  "done",
+  "ask",
+  "think",
+  "talk"
+]
    • addedInput schema / properties / text / description
      Added value: +"One line, at most 280 characters."
    • addedInput schema / properties / text / maxLength
      Added value: +280
  2. First observedv1.32.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare only the generic profile (not read-only, not idempotent, not destructive, not open-world). The description adds genuinely non-derivable behavior: it interrupts a human and misuse gets the companion disabled, and over-280-character text is refused rather than truncated — a hard failure mode, not a silent clamp.

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, then restraint rules, then a hard limit, then the return shape — every sentence carries information. It is slightly prose-heavy (the chattering-companion rationale could be tightened) and restates the 280-character cap already in the schema.

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?

With no output schema, the description still closes the loop by naming the return value (`said: <text>`), and it covers the failure mode and the restraint policy for a tool whose only real risk is overuse. Nothing needed to call this correctly is missing.

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 the baseline is 3, but the description goes further by giving the `mood` enum semantic weight — `ask` means the agent is actually blocked and waiting on the user, which the schema's 'expression' text does not convey. The 280-character limit is repeated from the schema, which is mild redundancy rather than added meaning.

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?

The description states a specific verb (say one line) and a specific channel (through Reado's mascot, described for an agent that has never seen it), and it implicitly distinguishes itself from the notification-oriented siblings by framing itself as a human-facing interrupt rather than browser instrumentation. An agent can select it correctly without opening the 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?

It gives an explicit positive trigger (the moment the user must know about while away: what you need, or what just landed) and an explicit negative list (not narration, not progress, not running commentary), plus a routing rule for the `ask` mood: use it only when actually waiting. This is about as unambiguous 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