Skip to main content
Glama
colinhallett

message-cp

by colinhallett
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

set_status

Sets a short status note visible next to your name in the agents panel and direct conversations; it expires after 5 minutes, clears on successful send/post, or immediately with empty text.

Instructions

Set your own status line: a short note on what you are doing, such as "reading Linear", which the dashboard shows next to your name in its agents panel and in the header bar of an open direct conversation with you. It replaces any line you set before. It stops showing 5 minutes after it was set, and is cleared when a send_message or post of yours succeeds and when you are unregistered or removed. Empty text, or only spaces, clears it now. Returns status (the line as stored, or null) and expiresAt (null with no line). Sends nothing and marks nothing read. Requires register first.

Input Schema

NameRequiredDescriptionDefault
textYesThe line, at most 100 characters, or empty or only spaces to clear it. A newline, other control character or bidirectional formatting character is refused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.6/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does so: TTL of 5 minutes, automatic clearing on successful send_message/post and on unregister/removal, replacement of any prior line, whitespace-only clears immediately, and no read-state side effects. It even documents the return fields (status, expiresAt) despite no output schema.

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 primary purpose, then lifetime and clearing rules, then return value and prerequisites. Dense but every clause conveys distinct behavioral information; only minor tightening (e.g. the parenthetical about expiresAt) is possible.

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?

For a single-parameter mutating tool with no annotations and no output schema, the description covers lifetime, clearing triggers, replacement semantics, side-effect absence, return shape, and the register prerequisite — nothing an agent needs to call it 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 baseline is 3, but the description adds semantic meaning beyond the schema: empty or spaces-only clears the status now, and setting a new value replaces the prior one. The 100-char limit and character restrictions live in the schema, so the description need not repeat them.

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 and resource ("Set your own status line") plus where it surfaces (agents panel, header of a direct conversation), which makes it unmistakable against siblings like send_message and post. The example line ("reading Linear") makes the concept concrete.

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 clear operating context: it is a 5-minute ephemeral note, it is superseded on the next successful send_message or post, and it requires register first. It also explicitly excludes message-sending behavior ("Sends nothing and marks nothing read"), which routes the agent away from send_message/post. It stops short of an explicit "use this when… / don't use it when…" statement, keeping it at 4.

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