Skip to main content
Glama

Followin MCP

by io.followin.mcp
OverviewDiscussionsAdmin

Watchlist Inbox

subscription

PURPOSE: Manage a free per-key KOL-call watchlist inbox for watch / subscribe / alert / remind / notify / monitor intents — save symbols, check unread counts, then fetch content with signal when needed.

COVERS (by intent):

  • [subscription-watchlist] watch / subscribe / alert me / remind me / notify me / monitor a symbol for new KOL calls; save or update a KOL-call watchlist; list watched symbols and unread counts; check whether watched coins or stocks have unseen KOL calls; acknowledge counts I already saw

BOUNDARIES:

  • Choose subscription when the user asks to watch, subscribe, alert, remind, notify, monitor, list subscriptions, check alerts, show watched symbols, or check unread KOL-call counts. It returns symbols and unread counts with zero monthly quota cost.

  • For the actual calls and original posts, use signal(categories=["kol_call"], keywords=[...]) after list reports symbols with unread_count > 0; that follow-up signal call is billed as usual.

  • Phase 1 supports category="kol_call" only, covering both crypto and tradfi KOL calls. Use per-item asset_type="crypto"|"tradfi" only to disambiguate a symbol.

  • Delivery model: pull-based watchlist inbox for user "alert/remind/notify me" wording; users can check stored unread counts later.

USAGE:

  • set: action="set", items=[{"symbol":"BTC","asset_type":"crypto"},{"symbol":"AAPL","asset_type":"tradfi"}]; this adds new items, ignores duplicates, and preserves existing items

  • list: action="list" (free; returns the watchlist with unread_count and folds pending updates into shown; repeated list calls are stable until ack)

  • ack: action="ack", items=[{"symbol":"BTC","asset_type":"crypto"}] (free; clears shown only)

  • delete: action="delete" (clears the whole watchlist)

RETURNS: results.watchlist for set/list, results.acknowledged for ack, or results.status for delete. set watchlist rows include symbol and asset_kind; list watchlist rows also include pending, shown, unread_count, and latest_ts where relevant.

EXAMPLES:

  • "帮我盯一下 BTC 和 ETH 有新喊单就提醒" → action="set", items=[{"symbol":"BTC","asset_type":"crypto"},{"symbol":"ETH","asset_type":"crypto"}]

  • "watch / subscribe / alert me on NVDA KOL calls" → action="set", items=[{"symbol":"NVDA","asset_type":"tradfi"}]

  • "我的自选币有新动静吗 / check my alerts" → action="list"

  • "我订阅的信号有更新吗 / show my subscriptions" → action="list"

  • "BTC 的提醒我看过了" → action="ack", items=[{"symbol":"BTC","asset_type":"crypto"}]

  • "列出我的订阅" → action="list"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsNoWatchlist items to set or ack. Required for set and ack. set never deletes existing items; use delete to clear the watchlist. Each item has a symbol and optional per-item asset_type for crypto/tradfi disambiguation.
actionYesAction to perform: set | list | delete | ack. Use set for user wording like watch, subscribe, alert me, remind me, notify me, or monitor a KOL-call symbol; use list for check/show my alerts, subscriptions, watched symbols, or unread counts; delete removes all items; ack clears shown unread state for supplied items.
categoryNoSignal category for this watchlist inbox. Phase 1 supports only kol_call; omitted defaults to kol_call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Adds substantial context beyond annotations: zero quota cost for this tool, pull-based delivery model, set preserves existing items while delete clears the whole watchlist, ack clears only shown state. One caveat: the annotations set destructiveHint=false, yet the delete action wipes the entire watchlist, which is a mild tension worth noting rather than a flat contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with PURPOSE and cleanly sectioned, but verbose: the COVERS and BOUNDARIES sections both re-list the same trigger keywords, and the EXAMPLES largely restate the USAGE examples. Several sentences duplicate what the schema already states about action semantics.

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?

Despite having no output schema, the RETURNS section documents the response shape per action (results.watchlist / acknowledged / status) and the row fields (pending, shown, unread_count, latest_ts). Combined with phase limitations and billing notes, an agent has everything needed to call it correctly.

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 description coverage is 100%, so baseline is 3. The description goes further by mapping each action enum value to concrete user phrasings, giving literal call examples with items payloads, and clarifying category="kol_call" is the only supported value in Phase 1.

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 names a specific resource and scope ("free per-key KOL-call watchlist inbox") and enumerates the four actions it supports. It explicitly distinguishes itself from the sibling signal tool, which retrieves the actual calls. An agent can tell exactly what this tool does versus its alternatives.

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?

The BOUNDARIES section states explicit when-to-use triggers (watch/subscribe/alert/list/ack) and routes the follow-up case to signal(categories=["kol_call"]) with the condition (unread_count > 0), including that the follow-up is billed. It also names the when-not case (fetching actual content).

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

All Followin MCP 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