iposignal

IPO social sentiment (premium)

get_ipo_social_sentiment

Read-only

Get IPOSignal's X/Twitter social-sentiment reading for a specific IPO — an aggregate of how investors are discussing the stock on X, scored from -1 (bearish) to +1 (bullish) with a label, post tallies, and a one-line summary. The reading is taken once, before listing, and not refreshed: ageDays says how old it is and reliable is false when too few posts back it. Returns the aggregate signal only, not the underlying posts. Provide exactly one of companyId, symbol, or cik. PREMIUM: paid per call over x402 (USDC on Base); an unpaid call returns the payment terms, and a not-found is never charged. Same data and price as the HTTP endpoint /api/agent/social-sentiment.

Input Schema

TableJSON Schema

Name	Required	Description
`cik`	No	SEC Central Index Key, with or without leading zeros, e.g. 1876042 or 0001876042.
`symbol`	No	US ticker symbol, e.g. CRCL. Case-insensitive. Tickers get reassigned, so a response may carry a symbolNote.
`companyId`	No	IPOSignal company id (24-character hex), as returned by other IPOSignal responses.

Output Schema

TableJSON Schema

Name	Required	Description
`label`	No	Bullish, Neutral or Bearish.
`score`	No	-1 (bearish) to +1 (bullish).
`symbol`	No	Ticker.
`ageDays`	No	Days since the reading. Readings are taken before listing and not refreshed.
`company`	No	Registrant name.
`summary`	No	One-line summary.
`reliable`	No	False when too few posts back the reading.
`postCount`	No	Posts the reading is based on.
`analyzedAt`	No	ISO timestamp of the reading.
`symbolNote`	No	Present only when the requested ticker is contested: which registrant it belongs to now vs. the record served.
`negativeHits`	No	Posts scored negative.
`positiveHits`	No	Posts scored positive.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 23, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "ageDays": {
+      "description": "Days since the reading. Readings are taken before listing and not refreshed.",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "analyzedAt": {
+      "description": "ISO timestamp of the reading.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "company": {
+      "description": "Registrant name.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "label": {
+      "description": "Bullish, Neutral or Bearish.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "negativeHits": {
+      "description": "Posts scored negative.",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "positiveHits": {
+      "description": "Posts scored positive.",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "postCount": {
+      "description": "Posts the reading is based on.",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "reliable": {
+      "description": "False when too few posts back the reading.",
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "score": {
+      "description": "-1 (bearish) to +1 (bullish).",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "summary": {
+      "description": "One-line summary.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "symbol": {
+      "description": "Ticker.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "symbolNote": {
+      "anyOf": [
+        {
+          "additionalProperties": true,
+          "properties": {},
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Present only when the requested ticker is contested: which registrant it belongs to now vs. the record served."
+    }
+  },
+  "type": "object"
+}

Changed3 schema fields changedSep 23, 2026

addedInput schema / properties / cik / description

Added value: +"SEC Central Index Key, with or without leading zeros, e.g. 1876042 or 0001876042."

addedInput schema / properties / companyId / description

Added value: +"IPOSignal company id (24-character hex), as returned by other IPOSignal responses."

addedInput schema / properties / symbol / description

Added value: +"US ticker symbol, e.g. CRCL. Case-insensitive. Tickers get reassigned, so a response may carry a symbolNote."

AddedMay 29, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: the reading is a static snapshot taken before listing and not refreshed, ageDays indicates age, reliable is false with insufficient posts, and it returns only the aggregate signal, not underlying posts. It also explains unpaid call behavior and that not-found is never charged. No contradictions with annotations.

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?

The description is well-structured and front-loaded with the core purpose, followed by data specifics, usage constraint, and premium details. Every sentence contributes useful information without redundancy. It is longer than minimal but each part earns its place.

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 an output schema present, the description need not enumerate return fields, but it still clarifies key aspects like the aggregate nature, ageDays and reliable fields, and the premium payment behavior. It provides enough for an agent to call the tool correctly, though it doesn't address alternative tool selection, which is covered under usage guidelines.

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?

The input schema already provides full descriptions for all three parameters (100% coverage). The description adds the critical constraint that exactly one of companyId, symbol, or cik must be provided, which is not enforced by the schema (required parameters: 0). It also mentions that symbol may carry a symbolNote, which is already in the schema but is reinforced.

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 clearly states the tool retrieves an X/Twitter social-sentiment reading for a specific IPO, with specifics about scoring, label, post tallies, and summary. It is specific about the resource and the aggregate nature, but it does not explicitly differentiate itself from the sibling get_ipo_sentiment tool, so it doesn't fully meet the 'distinguishes from siblings' bar.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage instruction that exactly one of companyId, symbol, or cik must be provided, and it notes the premium per-call cost, implying use only when sentiment data is needed. However, it does not mention when to prefer this over the sibling get_ipo_sentiment tool or when to avoid it, so guidance on alternatives is missing.

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

All iposignal tools Inspect

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.