Skip to main content
Glama

SocialToAI

by com.socialtoai
OverviewDiscussionsAdmin

Watch for what is new

watch
Destructive

Watch for the user: a search, action, op or tool run again by us every day or week, delivering only what is new to email, webhooks, a Feishu/WeCom/Slack chat, an RSS feed and watch_news. Two steps. action=preview with run (tool, action or op), inputs (as it takes them), every, time, timezone, name, delivery: tell the user preview.display. Only after they agree, action=confirm with its token. list shows each watch's feed URL; pause, resume, delete, rotate_feed and revoke_feed take id. Each run is charged as the call itself; a free account keeps 1 watch. On error, follow error.fix.

Input Schema

NameRequiredDescriptionDefault
idNoThe watch's (from list), for pause, resume, delete, rotate_feed or revoke_feed.
runNoWhat runs each time: a tool (brand_buzz), an action (search) or an op.
nameNoA short name, in the user's words.
timeNoHH:MM, 09:00 unless given.
everyNoday unless given.
tokenNoThe preview's, to confirm it.
actionYes
inputsNoIts inputs, as that tool takes them.
deliveryNoemail, webhook, both (email unless given), or the user's group bot webhook URL (Feishu/Lark, WeCom, Slack) to post new items to that chat.
timezoneNoThe user's IANA time zone.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "preview",
-  "confirm",
-  "pause",
-  "resume",
-  "delete"
-]New value: +[
+  "preview",
+  "confirm",
+  "list",
+  "pause",
+  "resume",
+  "delete",
+  "rotate_feed",
+  "revoke_feed"
+]
    • changedInput schema / properties / delivery / description
      Previous value: -"email unless given."New value: +"email, webhook, both (email unless given), or the user's group bot webhook URL (Feishu/Lark, WeCom, Slack) to post new items to that chat."
    • removedInput schema / properties / delivery / enum
      Removed value: -[
-  "email",
-  "webhook",
-  "both"
-]
    • changedInput schema / properties / id / description
      Previous value: -"The watch's, to pause, resume or delete it."New value: +"The watch's (from list), for pause, resume, delete, rotate_feed or revoke_feed."
  2. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, so the description doesn't need to re-declare that. It adds real context beyond the annotations: every run is billed as the underlying call, a free account can hold only one watch, and failures should be handled via error.fix. It does not spell out what delete or revoke_feed actually destroys (does deleting a watch remove its feed history?), which is the main behavioral gap for a destructive tool.

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?

Purpose is front-loaded and every sentence carries new information: workflow, action routing, billing, quota, error path. The first sentence is a 45-word chain of delivery targets and the 'list shows each watch's feed URL; pause, resume, delete...' line packs five actions into one clause, which costs readability. Dense but essentially fluff-free.

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 10-parameter, nested-input, destructive tool with no output schema, the description covers the two-phase commit, quota, billing, and error recovery, which is most of what an agent needs. It leaves out what a watch looks like once created (fields returned by list) and what happens to an existing watch when a new preview is made, gaps that matter given destructiveHint=true.

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 90%, so the baseline is 3, and the description earns above that by binding parameters to workflow steps (preview takes run/inputs/every/time/timezone/name/delivery; confirm takes token; id-taking actions are grouped). The note that inputs must be 'as that tool takes them' is useful framing for the nested object. It doesn't clarify what preview.display contains or how token lifetime works.

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 opening states a concrete verb+resource (a saved search/action/tool run repeated daily or weekly, delivering only new items) and enumerates delivery channels, which is far more than a restatement of the name 'watch'. It is not differentiated from the sibling watch_news or account_watch, which sound closely related, and the phrase 'delivering ... and watch_news' is ambiguous about whether watch_news is a channel or a separate tool.

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?

The description gives an explicit operating procedure: call action=preview first, show the user preview.display, and only then call action=confirm with the token. It also routes the remaining actions (list, pause, resume, delete, rotate_feed, revoke_feed) to the id parameter, so an agent knows which action to pick. It never says when a user should prefer this over watch_news or account_watch, so the alternative-selection layer is missing.

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

All SocialToAI toolsInspect
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