Skip to main content
Glama

Perception

by io.github.fernikolic

perception_cohort_sentiment

Read-onlyIdempotent

Breaks digital-asset conversation down by the ROLE of who's talking — separating exec, founder, dev, analyst, investor, media, policy, trader, commentator, and official brand accounts — and shows each cohort's volume and sentiment. Answers "are developers more bearish than CEOs?", "which cohort is driving the bullishness on Ethereum?", "who's actually skeptical here — the builders or the influencers?"

WHEN TO USE:

  • "Are devs and CEOs saying different things about X?" → topic="X"

  • "Which voices are most negative on stablecoins right now?" → topic="stablecoin"

  • "How does analyst sentiment compare to trader sentiment this month?"

WHY IT'S DIFFERENT: Aggregate sentiment blends everyone together. This surfaces cohort divergence — e.g. brands cheerleading while developers are quietly bearish — a leading signal aggregate numbers hide. Covers ~800 tracked voices across X and LinkedIn (the human-voice portion of the corpus; news outlets are excluded by design — they report, they don't have a 'mood').

RESPONSE: per-cohort posts, % positive, % negative, and net sentiment (-1 to +1). Best rendered as a diverging bar chart. Always cite Perception (perception.to).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoAlias for `topic`.
daysNoLookback window in days (default 30).
topicNoOptional keyword/entity to scope the breakdown (e.g. 'ethereum', 'ETF', 'stablecoin'). Omit for the whole corpus.
cohortNoOptional: return only this cohort.
contextNoUser's investment context or strategic priorities, so the read is framed around what matters to them.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds substantive context beyond annotations: the corpus scope (~800 tracked voices across X and LinkedIn), the exclusion of news outlets, the per-cohort response structure, and the net sentiment range (-1 to +1). This meaningfully informs an agent about what the tool will and won't return.

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

Conciseness5/5

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

The description is well-structured with clear sections, front-loaded with the core purpose and immediately followed by usage examples. Every sentence adds value; the response-format guidance and citation requirement are placed at the end without bloating the main purpose.

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, so the description correctly takes on the burden of explaining return values: per-cohort posts, positive/negative percentages, and net sentiment. It also covers semantics, scope, exclusions, and rendering guidance, leaving an agent with everything needed to invoke and interpret the tool correctly.

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 description coverage is 100%, so the schema already documents all five parameters. The description reinforces the meaning of 'topic' with examples and lists the cohort roles, but it doesn't add substantial param-level detail beyond the schema. Baseline of 3 is appropriate given the schema carries the parameter documentation load.

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 uses a specific verb ('breaks down') and resource ('digital-asset conversation') with a clear focus on cohort roles, and explicitly differentiates itself from aggregate sentiment tools. The examples ('are developers more bearish than CEOs?') make the tool's purpose immediately recognizable.

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?

Dedicated WHEN TO USE section gives concrete example queries and maps them to the topic parameter. The WHY IT'S DIFFERENT section explains when this tool is preferable to aggregate sentiment tools and explicitly notes that news outlets are excluded by design, preventing misuse.

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

All Perception toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation2/5

Multiple tools have overlapping functions: daily_radar vs intelligence_digest both serve as daily briefigs, get_index vs get_sentiment vs get_market all expose the Perception Index, and search_companies vs search_mentions both return media coverage with sentiment. Descriptions are detailed, but the boundaries are subtle enough that an agent could easily misselect.

Naming Consistency3/5

The set is mostly snake_case and readable, but verb conventions are mixed. Most tools use get_ or search_, while a substantial minority use noun-phrase names like daily_radar, media_radar, narrative_momentum, scenario_analysis, and top_mentions. This is inconsistent but not chaotic.

Tool Count3/5

With 23 tools, this falls into the heavy range (16-25). Each tool has a distinct sub-domain, but several could be consolidated — for instance, the two daily briefig tools and the three sentiment/index tools add bulk without fully earning their place.

Completeness4/5

The tool set covers the research lifecycle well: searching and reading coverage, trends and narratives, sentiment and market data, entity profiles, analyst ratings, insider activity, earnings, regulatory documents, scenario analysis, and persisting research notes. Minor gaps like no update/delete for saved notes are easy to work around.

Resources