What can you do with this server?

The Shingou server provides access to a news-sentiment API for financial assets (primarily cryptocurrencies), enabling retrieval and analysis of market sentiment signals. * get_sentiment — Fetch the latest news-sentiment signal for up to 50 symbols in a single call. Returns a score (−1 to 1), confidence (0 to 1), direction, dominant event types, and source articles. Signal updates hourly; free-tier users get a 24-hour delay on non-major symbols (outside BTC-USD, ETH-USD, SOL-USD). * get_sentiment_history — Retrieve a historical time-series of sentiment data for a single symbol for backtesting. Supports multiple intervals (1m, 5m, 15m, 1h, 4h, 1d), capped at 90 days per request. Flags reconstructed buckets rebuilt from archival news rather than live-collected data. * get_events — Fetch recent classified market events for a symbol (up to 100), including critical kill-switch types such as hack_exploit, regulation, and delisting, with headlines and source links. * list_symbols — Retrieve the full supported symbol universe along with free-plan freshness metadata. Requires no API key and consumes no quota — useful for discovery before authenticating.

shingou

by shingou-io

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Shingou skills

Glama score

Plug the Shingou point-in-time crypto market sentiment API into Claude or any AI agent. This repo is a skill that teaches the agent to use the API correctly (auth, symbols, quotas, and honest framing of an hourly signal), plus MCP tools for direct access.

Works instantly with a free API key (shingou.io/dashboard, no card). The paid key is what removes the 24h delay outside the live majors, and what buys history depth.

Path	What it is
`plugins/shingou/skills/shingou-api/`	The skill: SKILL.md + full API reference + worked flows
MCP endpoint	`https://api.shingou.io/mcp` — the same API as callable tools
`src/stdio-proxy.mjs`	Packaged stdio server, for hosts that launch a local process instead of connecting to a remote one

Install

Claude Code (plugin)

/plugin marketplace add shingou-io/shingou-skills
/plugin install shingou@shingou-skills

Then export your key so the agent can use it:

export SHINGOU_API_KEY=sk_live_...

claude.ai (skill upload)

Zip the skill folder (folder at the zip root) and upload it under Settings → Capabilities → Skills:

cd plugins/shingou/skills && zip -r shingou-api.zip shingou-api

There are no environment variables on claude.ai — the skill will ask you for the API key in-conversation.

Any other agent

Point your agent at plugins/shingou/skills/shingou-api/SKILL.md (plain markdown, no Claude-specific machinery), or at the live LLM-oriented reference: shingou.io/llms-full.txt.

Related MCP server: Web3 Signals — Crypto Signal Intelligence

MCP

Connect the Shingou API as tools (get_sentiment, get_sentiment_history, get_events, get_symbols) over Streamable HTTP. The Claude Code plugin configures this automatically — with SHINGOU_API_KEY exported, the shingou MCP server is ready after /plugin install. To connect without the plugin:

claude mcp add --transport http shingou https://api.shingou.io/mcp \
  --header "x-api-key: sk_live_..."

Requests made through MCP are attributed server-side — no User-Agent handling needed. claude.ai remote connectors (OAuth) are planned.

Packaged server (stdio)

Streamable HTTP is the way in, and every client above uses it. Two places cannot: hosts that only launch a local process, and directories that index a server by building it and speaking MCP to its stdin. src/stdio-proxy.mjs bridges both to the same remote endpoint. No dependencies, one HTTP POST per JSON-RPC message.

Published to npm, so a host that launches a local process needs no clone:

claude mcp add shingou -- npx -y @shingou-io/mcp-stdio

No build step, no dist/, no dependencies: the entrypoint is plain JavaScript and runs on Node 18 or newer. It was TypeScript until 0.3.1, which cannot work from an installed package, because Node refuses to strip types for anything under node_modules on every version.

From a clone or an image instead:

SHINGOU_API_KEY=sk_live_... node src/stdio-proxy.mjs

docker build -t shingou-mcp-stdio .
docker run -i --rm -e SHINGOU_API_KEY=sk_live_... shingou-mcp-stdio

SHINGOU_MCP_URL overrides the endpoint. The key is optional: initialize, tools/list and get_symbols all answer without one, so a client can discover the tools before the user has a key. The data tools need it.

Two layers of checks, split by what a failure would mean:

node --test test/proxy.test.ts   # hermetic: stub upstream, no network, no key
scripts/smoke.sh                 # live: builds the image, talks to the real endpoint

The first is what CI runs, verbatim and with no package manager, because it fails only when the bridge regresses. scripts/smoke.sh runs on a daily schedule instead — it can go red because the API moved or a deploy is mid-flight, and that should not block a pull request.

Quota math (free tier)

1,000 requests/day, 30/min burst. The signal changes once per hour per asset, and one /v1/sentiment call batches up to 50 symbols — so even polling the full universe every hour costs 24 requests a day. There is no reason to poll faster.

Free history reaches back one day, which is enough for /v1/history/sentiment to return a real series and not enough to backtest on. Depth is the paid axis: 90 days on starter, 365 on quant, 730 on pro.

What the signal is (and is not)

Point-in-time first. Every history bucket carries an as-of timestamp and a reconstructed flag, and the bucket's hash is committed to a public append-only log at publish time. So no lookahead is something you can check, not something we ask you to believe. The log is at shingou-io/shingou-signal-log.

The signal itself is one per asset per hour: score ∈ [-1, 1], confidence ∈ [0, 1], a direction call, dominant event types, and the source articles behind it. Measured performance, including the negative results, is published at shingou.io/research. The honest uses are filter, sizing, and kill-switch. Never an entry generator on its own. The skill instructs agents to disclose signal age (free-tier delays) and reconstructed history buckets rather than hide them.

License

MIT — see LICENSE. The skill and MCP tools are free distribution; the subscription is the data. API usage is governed by the Shingou terms (commercial use included on paid plans; free tier is for personal/evaluation use).

Not investment advice. This is an integration layer for a signal, not trading recommendations; backtest before risking anything.

Available Tools

4 tools

get_eventsTyped market eventsA

Read-onlyIdempotent

Recent classified market events for a symbol. Kill-switch trio: hack_exploit, regulation, delisting — the reference integrations stand aside for 24h after one. Report the event headline and source link, not just a risk flag.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max events (default 20)
`symbol`	Yes	One Shingou symbol, e.g. BTC-USD

TDQS

A4.7/5.0

Behavior5/5

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

Beyond annotations confirming read-only behavior, the description reveals the 'kill-switch trio' behavior where reference integrations stand aside for 24 hours, adding important behavioral context.

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 very concise, using two sentences plus a directive to convey purpose, behavioral quirks, and output expectations without unnecessary words.

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?

Given rich annotations, full schema documentation, and the lack of output schema, the description adequately explains what the tool does, how to use it, and what to report from the response.

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 coverage is 100%, but the description adds value by noting the default limit (20) and providing an example symbol format, which are not fully captured in schema descriptions.

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 clearly states the tool retrieves 'Recent classified market events for a symbol' and distinguishes itself from siblings like sentiment tools by specifying event types and reporting expectations.

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?

The description provides usage guidance by instructing to report the event headline and source link, but it does not explicitly state when not to use this tool or suggest alternatives.

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

get_sentimentLatest sentimentA

Read-onlyIdempotent

Latest news-sentiment signal per symbol (batch up to 50 in one call — one signal per asset per hour, so never poll faster than hourly). On the free plan, symbols outside BTC-USD/ETH-USD/SOL-USD are 24h delayed: check timestamp and disclose staleness.

ParametersJSON Schema

Name	Required	Description	Default
`symbols`	Yes	Shingou symbols, e.g. ["BTC-USD","ETH-USD"] (see get_symbols)

TDQS

A4.6/5.0

Behavior5/5

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

Adds significant behavioral info beyond annotations: batching limit, rate limit (hourly), free plan delay, timestamp disclosure requirement. No contradictions with readOnlyHint/idempotentHint.

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?

Two concise sentences, each dense with actionable information. Front-loaded with main purpose and batching. No fluff.

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?

Covers key aspects: batching, rate limits, plan differences, timestamp. Lacks explanation of return value structure, but acceptable for simple signal tool without output schema.

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 covers 100% of parameters. Description adds symbol format ('Shingou symbols'), example, and reference to get_symbols. Baseline 3 plus extra value.

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?

Description clearly states it returns 'Latest news-sentiment signal per symbol' with batching up to 50. Distinguishes from sibling 'get_sentiment_history' via 'latest' and from 'get_symbols' by purpose.

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?

Explicitly states when to use: batching allowed, polling frequency (hourly). Notes free plan delays and need to check timestamp. Does not explicitly contrast with get_events, but provides clear context.

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

get_sentiment_historyPoint-in-time sentiment historyA

Read-onlyIdempotent

Point-in-time sentiment series for backtesting: bucket is the as-of time, no lookahead. from/to are clamped to your plan's history window and to its per-request span, then echoed back — check them rather than assuming. reconstructed: true buckets were rebuilt from archival news, not live-collected; disclose the mix in any backtest.

ParametersJSON Schema

Name	Required	Description
`to`	Yes	Range end, ISO 8601
`from`	Yes	Range start, ISO 8601, e.g. 2026-06-27T00:00:00Z
`symbol`	Yes	One Shingou symbol, e.g. BTC-USD
`interval`	No	Bucket size (default 1h)

TDQS

A4.7/5.0

Behavior5/5

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

The description goes well beyond the annotations (readOnly, openWorld, idempotent). It discloses three behavioral traits: no lookahead, clamping of from/to to plan limits, and the reconstructed flag meaning archival vs live-collected data. This adds critical context for backtesting integrity that annotations alone do not provide.

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?

Three dense sentences, each earning its place: purpose + no-lookahead, clamping behavior, and reconstructed flag. Front-loaded and focused. No filler words or repetition of schema details.

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 no output schema, the description tells the user the key return semantics (bucket as-of time, reconstructed flag) and range clamping. It addresses the main risks (lookahead bias, range truncation, data provenance) for a backtesting tool. Sibling context and annotations complement it, making the description sufficient.

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 already covers all 4 parameters with descriptions (100% coverage), so baseline is 3. The description adds meaningful context for 'from'/'to' by explaining they are clamped and echoed back, and clarifies the output field 'bucket' as the as-of time. This extra value justifies a 4.

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 clearly states the tool provides a 'point-in-time sentiment series for backtesting', specifying both the resource (sentiment history) and its distinct purpose (backtesting) with the critical no-lookahead guarantee. This distinguishes it from sibling tools like get_sentiment (likely current sentiment) and get_events.

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?

The description explicitly frames this tool for backtesting, giving a clear context for when to use it. It does not explicitly name alternatives or state when not to use it, but the backtesting context implies this is the historical counterpart to real-time sentiment tools. Minor deduction for lack of explicit exclusionary guidance.

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

get_symbolsSupported symbolsA

Read-onlyIdempotent

The supported symbol universe with each symbol's free-plan freshness. Static — costs no quota and needs no API key.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already indicate read-only and idempotent. Description adds value by stating no quota cost and no API key requirement, and the static nature.

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?

Two sentences, no fluff. Front-loaded with purpose. Every word serves a 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?

Given zero parameters, rich annotations, and simple purpose, the description fully covers the tool's behavior and context.

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?

No parameters to describe. Description appropriately does not add parameter info since none exist. Baseline of 4 applies.

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 clearly states it returns the supported symbol universe with free-plan freshness. It differentiates itself from sibling tools (get_sentiment, etc.) by focusing on symbols.

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?

Description mentions it is static, costs no quota, and needs no API key, implying low-risk usage. Lacks explicit exclusions or alternatives but context is clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv0.3.1Jul 29, 2026

Changedget_sentiment1 field changed

changedInput schema / properties / symbols / description

Previous value: -"Shingou symbols, e.g. [\"BTC-USD\",\"ETH-USD\"] (see list_symbols)"New value: +"Shingou symbols, e.g. [\"BTC-USD\",\"ETH-USD\"] (see get_symbols)"

Addedget_symbols
Removedlist_symbols

4 tool updatesv0.1.0Jul 29, 2026
- First observedget_events
- First observedget_sentiment
- First observedget_sentiment_history
- First observedlist_symbols

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0

Scored 2026-08-02 16:20 across 4 tools

Disambiguation5/5

Each tool serves a distinct, non-overlapping purpose: current sentiment, historical sentiment, events, and symbol universe. There is no ambiguity in selecting between them.

Naming Consistency5/5

All tool names follow a consistent 'get_<resource>' pattern, making the API predictable and easy to navigate.

Tool Count5/5

With 4 tools, the server is well-scoped for a sentiment/events data provider. Each tool earns its place without unnecessary bloat or missing essentials.

Completeness5/5

The tool set covers the full spectrum of the domain: current sentiment, historical series for backtesting, event classification, and symbol metadata. No obvious gaps exist for the stated purpose.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Shingou A
io.shingou
Hourly crypto news sentiment and typed market events, with sources on every signal.
Cryptocurrency Blockchain
41
Gloria AI A
io.github.cryptobriefing-labs
Real-time curated crypto news for AI agents with sentiment, recaps, and search.
Cryptocurrency AI & Machine Learning Search
711
aTars MCP A
ai.aarna
Crypto market signals, technical indicators, and sentiment analysis for AI agents.
Cryptocurrency Finance Search
2
Stelar Signals B
io.github.StelarDigital
Crypto market signals and portfolio telemetry. 6 tools pay-per-call in USDC, no API key.
Cryptocurrency Finance
121

Related MCP Servers

Tradovate MCP Server
Finance Databases
alexanimal
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables interaction with the Tradovate API for managing trading contracts, positions, orders, and accounts.
Updated a year ago (2025-03-27 20:48 UTC)
1
MIT
Web3 Signals — Crypto Signal
Blockchain Finance Web3 & Decentralized Tech
manavaga
A
license
Not graded
quality
C
maintenance
AI-powered crypto signal intelligence for 20 assets (BTC, ETH, SOL, etc). 6 scoring dimensions: whale activity, technical analysis, derivatives flow, narrative strength, sentiment, market structure. Market regime detection (TRENDING/RANGING), portfolio optimization, and accuracy tracking. 9 read-only MCP tools. Free via MCP, $0.001 USDC via x402 on Base for REST API.
Updated a month ago (2026-08-17 17:39 UTC)
3
MIT
cryptopolitan-mcp
Cryptocurrency Search
4dmrkey
A
license
B
quality
F
maintenance
Real-time cryptocurrency news, analysis, and price predictions for AI agents. 5 tools to search 50,000+ articles across 12 categories, filter by 120+ asset tickers, and access content with built-in attribution. Free with attribution. SSE and Streamable HTTP transport.
Updated 5 months ago (2026-04-12 12:38 UTC)
4
MIT
mcp-crypto
Cryptocurrency Finance
pipeworx-io
A
license
Not graded
quality
C
maintenance
Provides cryptocurrency market data (top coins by market cap) and fiat currency exchange rates.
Updated 17 days ago (2026-08-26 16:51 UTC)
10
MIT