Skip to main content
Glama

Social media sentiment of the monitored names

social_sentiment
Read-onlyIdempotent

What public posts on social platforms say about the names the workspace monitors, the one list of Monitoring (companies, organisations, brands, persons and topics), searched once a day on X, LinkedIn, TikTok, Instagram, YouTube, Reddit and Threads and labelled by our reader. Every answer carries source.enabled; while it is false no search source is switched on and nothing current is read, and paused_until, set while the workspace's updates are paused until that day. Without target_id it lists the names in name order, each with its newest reading of a day read in full, or latest null while none is stored; node_id keeps the names matched to one company or person. With target_id it returns that name's daily readings, newest first (days, default 30), and its newest 100 posts of the last 30 days, each with its item_key, platform, url (null with link_withheld true when every form of the link would name a person), published_at, language, the reader's sentiment label, the matched_word and source_kind (organisation, media or person). A post the reader found to be about something else is never listed. A reading counts the posts of its 30 day window by platform and by sentiment; its state is reading (sentiment_net is positive minus negative over the rated posts, from -1 to +1), too_little_coverage or feed_gap. No author, handle, title or post text is ever kept. A person's reading is context for the bank's own diligence, never a score, rating or ranking of the person. A sole trader's name (held sole_trader) is never searched and carries no reading and no post; held not_read marks a name the daily search does not read yet. Each name carries days, its posts per day over the 30 days of its reading, oldest first, each day with read, positive, negative, neutral and unrated, and one name's answer adds platforms, the same day counts per platform. No reading is ever part of the risk score. A name outside the workspace's list answers 404.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "social_sentiment"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysNoDaily readings to return with target_id, default 30.
limitNoPage size, default 50, maximum 100.
offsetNoRows to skip, default 0.
node_idNoWithout target_id, only the names matched to this company or person node.
target_idNoThe monitored name's id; omit to list the names.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds substantial behaviour: a once-a-day search cadence, source.enabled gating and paused_until suspension, link withholding (url null with link_withheld true), suppression of off-topic posts, the meaning of reading states (reading/too_little_coverage/feed_gap), and sentiment_net's -1..+1 derivation. Privacy guarantees (no author, handle, title or post text kept) and the explicit statement that a reading is never part of the risk score are exactly the caveats an agent needs.

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?

The content is dense and mostly earns its place, but it is delivered as one long run-on paragraph with comma-chained clauses ('Every answer carries source.enabled; while it is false ... and paused_until, set while ...'). Splitting the list-mode behaviour, detail-mode behaviour and privacy rules into separate sentences would make it far easier to scan without losing information.

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, the description carries the full burden and mostly meets it: it enumerates post fields (item_key, platform, url, published_at, language, sentiment label, matched_word, source_kind), reading fields, and the per-day/per-platform counts structure. Gaps remain around pagination (limit/offset, whether total counts are returned) and how platforms is attached, so it is not fully complete.

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 the baseline is 3, but the description genuinely adds meaning beyond it: days governs daily readings for target_id (default 30), target_id toggles between list and detail mode, and node_id filters by matched company or person. limit and offset are never mentioned in the description, leaving pagination semantics to the schema alone.

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 states precisely what the tool returns: public posts on X, LinkedIn, TikTok, Instagram, YouTube, Reddit and Threads about the names the workspace monitors, labelled by the reader. It also distinguishes its two modes (list names without target_id, per-name readings with target_id). It never names a sibling such as company_social, so an agent must infer the workspace-scoped vs. company-scoped split from context.

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?

It gives clear selection rules for each parameter: omit target_id to list names in name order, supply target_id for that name's daily readings plus newest 100 posts, use node_id to keep only names matched to one company or person. It also states when data is absent (source.enabled false, paused_until, sole_trader, not_read, 404 for names outside the list). No explicit 'use X instead' alternative is offered, so 4 rather than 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources