Checks brand recommendation rank and GEO visibility across Perplexity as part of B2B buying-intent scans.
Filters live Reddit social streams to remove spam and shill posts, extracting authentic vendor switching intent, price complaints, and procurement RFQs.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CleanSignal MCP show the latest copper regime and hedging advice"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
De-noised Real-Time Market Regime, Commodity & B2B Buying-Intent Signals for AI Agents (Pay-Per-Call Wholesale MCP)
⚡ Click Here to Top Up 100 API Credits for Just $0.99 USD on Polar.sh
🌐 Official Live Portal & Interactive Sandbox: https://00112238.xyz/cleansignal/
Inspired by Silicon Valley's Credit-Led Growth (CLG) wholesale models (such as Treg / Dealroom MCP), CleanSignal MCP acts as an on-demand data faucet for Claude Code, Grok Bot, and Cursor.
Instead of subscribing to $2,000/mo enterprise Bloomberg or Apollo licenses, your AI agent can query CleanSignal for less than $0.01 per call to retrieve:
De-noised Commodity, FX & Freight Regimes: Instant basis, inventory percentiles, and physical inventory lock recommendations (Copper, Gold, Crude, CNH, Lithium, Aluminum, SCFI Freight).
Social Stream De-noiser: Filters 95%+ of bot spam and crypto shills from live X/Reddit streams to extract authentic vendor switching intent and procurement RFQs.
B2B Buying Signals & GEO Visibility: Discovers active tender RFQs across Industrial Machinery, Logistics, Medical Devices, and DTC E-Commerce, while checking brand recommendation rank across Perplexity/ChatGPT.
Add CleanSignal to your claude_desktop_config.json:
{
"mcpServers": {
"cleansignal": {
"command": "npx",
"args": ["-y", "github:wu00112238/cleansignal-mcp"]
}
}
}Related MCP server: agentpulse-mcp
Tool Name | Output Format | Description |
| JSON | Returns basis percentiles, order flow, and spot hedging advice for Copper/Gold/Crude/CNH/Lithium/Aluminum/SCFI. |
| JSON | Strips spam/shill posts from raw social feeds, tagging price complaints and procurement RFQs. |
| JSON | Scans active company expansion triggers and verifies buyer domains (Machinery, Logistics, Medical, DTC). |
| JSON | Returns the direct |
⚡ Starter Credit Pack ($0.99 USD): Buy 100 Metered API Calls Now
🌐 Official Live Portal & Interactive Sandbox: https://00112238.xyz/cleansignal/ (Less than $0.01/call, instant checkout via Apple Pay / Card).
MIT License. Copyright (c) 2026 CleanSignal Labs (wu00112238).
Instant $0.99 USD top-up link for 100 metered CleanSignal API calls via Polar.sh.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the price and Polar.sh as the payment provider, but does not clarify whether invoking it initiates a charge, returns a checkout URL, requires authentication, or is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clear sentence with no wasted words. The essential elements—price, quantity, product, and payment provider—are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no annotations or output schema, the description covers purpose, cost, and provider. However, it leaves out what invoking the tool actually does or returns, which is important for a purchasing flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There are no parameter semantics to explain, and the schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action (top-up/buy) and resource (100 metered CleanSignal API calls) with price and provider. It is clearly distinct from the unrelated sibling tools, though it does not explicitly name or contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The need to top up credits is implied by the description, but not framed as a usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
De-noises raw social/X streams: Strips crypto shills and bot spam, isolating high-purity vendor complaint and buying intent signals.
| Name | Required | Description | Default |
|---|---|---|---|
| rawPosts | Yes | Array of raw social media or forum post strings |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, yet it never states the return shape (filtered array? scored items? counts?), whether filtering is deterministic or model-based, or whether the call consumes credits despite a sibling named buy_cleansignal_credits. It does disclose the filtering criteria (crypto shills, bot spam), which is real behavioral content, but the operational gaps dominate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the action leading and the target signals trailing. It is efficient, though 'de-noises' and 'high-purity' are marketing-flavored rather than operational wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is the only source of truth about what comes back, and it never says. For a transformation tool whose entire value is the output, missing return-value description and credit/cost implications leave a material hole.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and schema description coverage is 100%, so the schema already documents rawPosts as an array of post strings. The description's mention of 'raw social/X streams' reinforces the input domain but adds no format, size, or batching detail beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific operation (de-noising / stripping spam / isolating complaint and buying-intent signals) on a specific resource (raw social/X streams). An agent can tell roughly what it produces, though the name-plus-description pair is somewhat jargon-heavy and does not distinguish it from the sibling scan_b2b_buying_intent, which appears to target the same signal class.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus scan_b2b_buying_intent, no stated prerequisites on input (e.g. minimum posts, language, date window), and no exclusions. The agent must guess at the boundary between filtering and scanning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns de-noised real-time commodity/FX market regime and physical hedging actions (Copper, Gold, Crude, CNH, Lithium, Aluminum, SCFI Freight).
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Commodity symbol (e.g. COPPER, GOLD, CRUDE, USDCNH, LITHIUM, ALUMINUM, SCFI) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It usefully signals that the data is de-noised and real-time and that the output includes physical hedging actions, but it does not describe permissions, data freshness constraints, return shape, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is a single front-loaded sentence with no wasted text. The commodity/FX list is compact and useful for setting scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter retrieval tool with high schema coverage, the description gives the minimum needed to understand what is returned. However, with no output schema, it does not explain the return structure, timeframe, or how to interpret the regime and hedging actions, leaving clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single required parameter has 100% schema description coverage and the schema already lists example symbols. The description repeats some examples but adds no additional symbol semantics or formatting rules beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Returns') and a clearly scoped resource: de-noised real-time commodity/FX market regime plus physical hedging actions. It lists the supported commodity/FX symbols, making its purpose distinguishable from the unrelated sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool returns but gives no explicit guidance on when to use it, when not to use it, or which alternatives to prefer. Sibling tools are unrelated, so the intended context is inferable, but the description itself provides no usage rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scans real-time verified B2B buying signals, active tender RFQs, and GEO AI visibility ranking (industrial_machinery, logistics, saas, medical_devices, dtc_ecommerce).
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | B2B category (e.g. industrial_machinery, logistics, saas, medical_devices, dtc_ecommerce) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does not say whether this is a read-only scan, whether it consumes credits (notable given the sibling buy_cleansignal_credits), or what the output looks like. 'Real-time verified' and 'GEO AI visibility ranking' are unexplained terms that leave the agent guessing about data freshness and shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with no filler. The trailing parenthetical duplicates the schema's enum examples, costing a bit of space without adding information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no output schema, the description covers what is scanned and for which categories. It leaves ambiguous whether a single category returns all three signal types or only the matching one, which is the one real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter is fully documented in the schema at 100% coverage, so a baseline of 3 applies. The description merely repeats the same category examples verbatim, adding no new semantics such as accepted aliases, case sensitivity, or whether multiple categories can be combined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Scans' paired with three named resource types (buying signals, tender RFQs, GEO AI visibility ranking) makes the operation clearly identifiable. It does not differentiate itself from siblings such as filter_social_signals, which covers adjacent signal territory, so an agent must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no exclusions, and no mention of the sibling tools (filter_social_signals, get_commodity_regime, buy_cleansignal_credits) as alternatives. Usage is only weakly implied by the category list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.2buy_cleansignal_creditsfilter_social_signalsget_commodity_regimescan_b2b_buying_intentScored across 4 tools
The four tools mostly target distinct jobs: commodity regime lookup, social-signal filtering, B2B intent scanning, and credit purchase. The main overlap risk is between filter_social_signals and scan_b2b_buying_intent, since both relate to extracting buying signals from external data, but their descriptions differentiate raw social-stream de-noising from verified B2B/tender scanning.
All tool names follow a consistent snake_case verb_noun pattern: get_, filter_, scan_, and buy_. The convention is predictable and readable throughout.
Four tools is on the thin side but appropriate for a focused signal/intelligence API with three data products plus billing. Each tool has a clear role, though the surface could feel slightly underpowered if the service grows.
The tool set covers the main signal products and a credit top-up, but there is no tool to check remaining credits, account usage, or subscription status. It also lacks history/time-series access for commodity regimes or signal streams, which are notable gaps for a metered data service.
100+ MCP tools for AI agents: content metadata, trade intelligence, business-expertise analysis.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Agent-ready economic, market & geo-health intelligence — 317 MCP tools, 309 driver-backed indices.
Social media analytics, video analysis, and competitor intel for any MCP-compatible AI agent.
