Skip to main content
Glama
Sign In

MangroveAI

by io.github.MangroveTechnologies
OverviewDiscussionsAdmin

get_social_sentiment

Read-onlyIdempotent

Keyword-polarity sentiment for a crypto cashtag on X/Twitter. It fetches recent posts for $TOPIC and counts how many contain a positive and how many a negative keyword; the 0-100 score is the positive share of those polar posts. Returns the score, a bullish (70 or more), neutral or bearish (30 or less) label, and the number of posts read. When no post carried a sentiment keyword the score is null and the label is insufficient_signal: report that, not a neutral reading. Always state how many posts the reading was built from. Use it when the user asks about market mood or social sentiment for a token. The call is metered, so ask once per topic and reuse.

[Access: pay 1.00 USDC via x402 (PAYMENT-SIGNATURE header) OR authenticate with an API key. An x402-capable client will auto-pay; API-key clients pay nothing per call.]

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "topic": "<topic>"
    },
    "name": "get_social_sentiment"
  }
}

Input Schema

NameRequiredDescriptionDefault
topicYesAsset symbol, project name or free-form topic.
hours_backNoLookback window in hours.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations (read-only, open-world, idempotent), it discloses the paywall model with concrete pricing (1.00 USDC via x402 or API key), how the score is computed, the exact label thresholds (bullish >=70, bearish <=30), and the null/insufficient_signal edge case with explicit reporting instructions. It also tells the agent to state the sample size, which is behavior an agent would otherwise get wrong.

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 purpose, then computation, then output shape, then usage and cost — a sensible order with no filler. It is dense and somewhat long, and the instruction to state post counts slightly repeats the return-value sentence, but nearly every sentence carries actionable content.

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?

There is no output schema, yet the description fully enumerates return fields (score, label, post count) and their semantics including the null case. Combined with the payment/authentication detail, nothing an agent needs to call and interpret this tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already documented in structured form. The description clarifies that topic is a cashtag symbol ($TOPIC) and that results are drawn from recent posts, but never mentions hours_back or how the lookback interacts with the metered call.

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 (crypto cashtag sentiment on X/Twitter) and states exactly the computation performed: count posts containing positive vs negative keywords and derive a 0-100 positive share. That level of specificity distinguishes it from a raw-mentions tool such as get_social_mentions without needing to name it.

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 a clear trigger ("user asks about market mood or social sentiment for a token") and a usage constraint ("ask once per topic and reuse" because calls are metered). It stops short of naming alternatives or stating exclusions, so an agent must infer when get_social_mentions or get_smart_money_sentiment would be the better pick.

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

All MangroveAI 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