cerebrus-pulse-mcp

by 0xsl1m

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.1
Disambiguation5/5
Each tool serves a unique purpose, from specific analyses like funding rates and liquidations to aggregated signals like the screener and bundle. Descriptions clearly differentiate them.
Naming Consistency5/5
All tools follow a uniform 'cerebrus_' prefix with descriptive, lowercase, snake_case names, making the set predictable and easy to navigate.
Tool Count5/5
With 15 tools, the server covers a broad range of analytics without being overwhelming. Each tool addresses a distinct aspect of Hyperliquid perpetual trading.
Completeness4/5
The toolkit is comprehensive, covering technical analysis, sentiment, funding, liquidations, OI, spreads, and more. Minor gaps exist (e.g., no raw price feed or historical data export), but core workflows are well-supported.
Average 4.1/5 across 15 of 15 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It states the tool checks health and is free, but does not explain what the response contains (e.g., status object, error codes), whether it requires authorization, or its reliability/availability. For a health check, typical details like response format or meaning of health indicators are missing.
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 extremely concise: two short sentences with zero wasted words. It front-loads the primary action and adds the free note as secondary. Every sentence adds value, and there is no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description should fully explain what the tool does and what it returns. While it states the purpose, it omits critical details about the response format (e.g., status codes, JSON structure) and any other behavioral traits (e.g., latency, error handling). For a health check tool, users need to know what to expect in the output to interpret the results correctly.
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 tool has zero parameters, and the input schema is empty with 100% coverage. According to guidelines, a baseline of 4 is appropriate when no parameters need explanation. The description does not need to add parameter semantics, so this score reflects the minimal but adequate handling.
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's purpose: checking the health status of the Cerebrus Pulse gateway. It uses a specific verb ('Check') and resource ('Cerebrus Pulse gateway health status'), and the name 'cerebrus_health' aligns with this purpose. The tool is distinct from sibling tools, which cover other financial data endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when or why to use this tool versus its siblings (e.g., before calling other tools, or as a prerequisite). It also does not mention any context or prerequisites, such as whether authentication is needed. The only additional note is that it's free, which is a minor benefit but not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It discloses the cost ($0.01 USDC via x402), which is helpful. However, it does not mention any destructive actions, rate limits, or other behaviors. With no annotations, the description is moderately transparent but lacks depth.
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 two sentences: the first states purpose and return values, the second states cost. No extraneous information. Every word is justified.
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?
Given the simple tool (one required parameter, no output schema, no annotations), the description is reasonably complete. It covers purpose, returned data, and cost. Could mention that coin is case-insensitive (schema already does) or add error handling details, but overall adequate.
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?
The schema covers the single parameter (coin) with 100% coverage, including a description. The tool description does not add additional meaning beyond the schema, only restating that it takes a coin ticker. Baseline is 3 for high schema coverage.
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's purpose: 'Get open interest analysis for a Hyperliquid perpetual.' It specifies the resource (OI analysis), action (get), and scope (Hyperliquid perpetual). It also lists the return values: OI delta, percentile rank, trend direction, and divergence signals, making it distinct from sibling tools.
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 implies usage for querying OI analysis, but does not explicitly state when to use this tool vs. alternatives (e.g., cerebrus_funding, cerebrus_sentiment). No when-not-to-use guidance is provided, leaving the agent to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the cost ($0.02 USDC via x402) and interprets output signals. It does not mention rate limits or auth needs, but the read-only analytic nature is clear. No contradictions.
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 sentences: first defines purpose, second describes returns, third states cost. Every sentence adds value, front-loaded, no redundancy.
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?
For a simple one-parameter tool, the description covers purpose, output, and cost. It lacks error behavior details but is sufficient for typical use. Sibling links provide additional context.
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% with a single 'coin' parameter described. The description does not add additional semantics beyond the schema, but it provides context on how the parameter is used in the analysis. Baseline 3 is appropriate.
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 explicitly states the tool retrieves Chainlink basis analysis comparing Hyperliquid perpetual oracle price vs Chainlink aggregated spot price on Arbitrum. It lists output fields (basis in bps, direction, contrarian signal) and cost, clearly distinguishing its purpose from siblings like cerebrus_funding or cerebrus_spread.
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 provides context for when basis analysis is relevant (e.g., positive basis means longs pay shorts), but it does not explicitly state when to use this tool instead of alternatives like cerebrus_funding or cerebrus_sentiment. Usage is implied but not delineated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It discloses the cost and the fact that it's a bundled call, but does not mention authentication, rate limits, or output structure. This is adequate but not comprehensive for a complex tool.
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 extremely concise, using a single sentence and two short clauses to convey the tool's purpose, components, discount, and cost. Every word adds value, with no redundancy.
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?
Given the tool's complexity as a bundle of multiple analyses and the lack of an output schema, the description sufficiently covers what the tool does and its cost. It helps distinguish from many sibling tools, but could benefit from a brief note on the output format.
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?
The input schema has 100% description coverage for both parameters (coin and timeframes). The description adds only marginal value, listing timeframes already in the schema and implying no additional constraints. Thus, the description does not significantly enhance parameter understanding beyond the schema.
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 provides a 'complete analysis bundle' combining multi-timeframe technical analysis, sentiment, and funding for a coin. It explicitly lists the timeframes and components, differentiating it from sibling tools that offer individual analyses.
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 mentions a '20% discount vs individual endpoints', implying this tool is cost-effective when needing all analyses together. However, it does not specify scenarios where the bundle would be inappropriate (e.g., if only one analysis type is needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full transparency burden. It discloses return fields (current rate, annualized %, historical min/max/average) and cost. It does not cover auth, rate limits, or side effects, but the core behavior is clear.
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 with no fluff. First sentence states purpose, second lists key return fields and cost. Every word adds value.
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?
Adequate for a simple tool with two parameters. Lists return fields despite no output schema. Missing details on error conditions or data freshness, but overall sufficient for an agent to understand what to expect.
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?
Input schema has 100% description coverage for both parameters. The description adds the context of 'Hyperliquid perpetual,' which scopes the 'coin' parameter, but does not elaborate on parameter semantics beyond the schema.
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 'Get funding rate analysis for a Hyperliquid perpetual,' specifying the verb (get), resource (funding rate analysis), and domain (Hyperliquid perpetual). This distinguishes it from sibling tools like cerebrus_basis or cerebrus_spread.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies Hyperliquid-specific use but does not state exclusions or prerequisites. The cost mention ($0.01 USDC) is useful but not a usage guideline per se.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must compensate. It discloses the cost ($0.04 USDC) and implies a read operation (scanning signals). However, it does not mention authorization needs, rate limits, or any side effects. The behavioral disclosure is partial but adds some value beyond typical.
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 two sentences, front-loading the action and key differentiators. Every sentence serves a purpose: first sentence states core functionality, second lists return fields and cost. No extraneous text.
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?
Given the tool's simplicity (single optional parameter, no output schema), the description covers the main behavior and output fields. It lists the return metrics (RSI zone, trend, etc.) to inform the agent. While it could detail the output format more, it is sufficient for selection and basic understanding.
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?
The input schema has one parameter (top_n) with 100% description coverage via the schema's own description. The tool description does not add additional semantic detail about the parameter; it mentions 'scan all 30+ coins' but the parameter defaults to 30, which is consistent. Baseline 3 is appropriate as schema fully documents the parameter.
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 scans all 30+ coins for top trading signals and lists the specific metrics returned (RSI, trend, volatility, etc.). It distinguishes from the sibling 'cerebrus_pulse' by noting it is cheaper for bulk scanning.
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 compares directly to cerebrus_pulse, saying it is much cheaper than calling pulse individually. This gives clear guidance on when to use this tool over that specific sibling. However, it does not provide guidance relative to other siblings like cerebrus_basis or cerebrus_funding, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description adds cost ($0.015 USDC via x402) and mentions scanning 8 chains, but lacks details on rate limits, response format, or side effects beyond being a read operation.
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 sentences, front-loaded with purpose and key outputs, no filler. Every sentence adds value.
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?
Given one parameter with full schema and no output schema, the description lists return fields (stress level, score, spread, chain routes, summaries) adequately, though format details are omitted.
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?
Parameter 'limit' is fully described in schema (1-50, default 10); description does not add meaning beyond schema, so baseline 3 is appropriate.
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 'Get market stress index' and lists specific outputs (stress level, score, spread, etc.), distinguishing it from siblings by claiming 'Unique signal — not available from any other provider.'
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?
Mentions uniqueness, implying use when alternative stress indices are insufficient, but does not explicitly exclude use cases or compare with sibling tools like cerebrus_basis or cerebrus_sentiment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description provides valuable behavioral details: refresh rate (5 min), cost ($0.02 USDC via x402), and return structure. This goes beyond the schema, though no rate limits or error handling are mentioned.
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?
Four sentences with no redundancy. Front-loaded with purpose, then adds refresh, cost, and return info efficiently.
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?
For a simple tool with one parameter, the description covers purpose, sources, outputs, refresh, and cost. No gaps evident given lack of output schema.
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% and the description adds minimal extra meaning: it mentions comparing exchanges but doesn't constrain the coin parameter further. Baseline 3 is appropriate.
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 the tool gets CEX-DEX price divergence, specifies sources (Coinbase vs Chainlink/Uniswap), and lists return values (spread in bps, direction, interpretation). It distinguishes from siblings like cerebrus_basis and cerebrus_spread.
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?
No explicit guidance on when to use this tool vs alternatives. The description implies usage for CEX-DEX divergence analysis but lacks exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the cost ($0.03 USDC via x402), which is a key behavioral detail. The action 'Get' implies a read operation, so no destructive behavior is expected. This is sufficient.
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 a single sentence that front-loads the action and key details. Every word adds value; no redundancy.
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?
Despite having no output schema, the description lists the returned information (correlation matrix, regime, sector averages). This provides sufficient context for an agent to understand the output, though format details are missing.
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?
There are no parameters (schema coverage 100% trivially). The description adds no parameter details, but none are needed. Baseline score of 4 is appropriate.
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's purpose: getting a BTC-altcoin correlation matrix for top 15 Hyperliquid perpetuals. It specifies outputs (30-day rolling correlations, correlation regime, sector averages) and distinguishes from siblings by focusing on correlation.
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?
While the description implies usage for correlation analysis, it does not explicitly state when to use this tool versus siblings like cerebrus_basis or cerebrus_sentiment. No exclusions or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full burden. It discloses cost ($0.03 USDC) and enumerates output details (cascade risk level, USD zones, proximity, ratio, alert). This goes beyond a basic purpose statement, but does not cover rate limits, data freshness, or auth requirements.
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 a single paragraph that efficiently conveys purpose, outputs, uniqueness, and cost. It is front-loaded with the primary function. Could be slightly more structured (e.g., bullet points), but no 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?
With no output schema, the description effectively enumerates output components (cascade risk, USD, proximity, ratio, alert). It also provides pricing and uniqueness. This is sufficient for an agent to understand what to expect from the tool.
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% with a single parameter. The description adds context by providing examples (BTC, ETH, SOL) and specifying 'Hyperliquid perpetual,' clarifying the domain. This adds meaning beyond the schema description's 'Case-insensitive' hint.
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 'Get estimated liquidation heatmap for a Hyperliquid perpetual.' It specifies the action (get), resource (liquidation heatmap), and platform (Hyperliquid). It distinguishes itself by noting 'No other MCP provider offers this signal,' which helps differentiate from siblings.
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 implies use when liquidation data is needed, but does not explicitly state when to use or avoid, nor does it mention alternatives among sibling tools. The cost disclosure provides some guidance but lacks when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions cost ($0.01 USDC) and output statuses (HEALTHY/ELEVATED/WARNING/CRITICAL, risk level, sequencer status). Missing details on failure modes 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with all essential information front-loaded. No 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 no output schema or annotations, the description fully explains the tool's purpose, what it checks, and the cost. Sufficient for an agent to decide to invoke it.
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?
Input schema has zero parameters, so no parameter info needed. Baseline of 4 for no parameters is appropriate.
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 USDC collateral health via Chainlink oracle, checking peg deviation and reporting multiple statuses. It is distinct from siblings like basis or funding tools.
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 indicates use 'before sizing USDC-margined positions,' providing clear context. No explicit exclusions or alternatives mentioned, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Clearly states cost $0.008 USDC and output structure. No destructive effects mentioned, appropriate for a read-only analytics tool. Sufficient but could mention rate limits or data freshness.
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 sentences: purpose, output details, cost. No redundancy or filler. Every sentence provides actionable info for an AI agent.
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?
For a single-parameter tool with no output schema, description fully covers input, output, and cost. Agent can invoke correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter 'coin' with full schema documentation. Description adds examples (BTC, ETH, SOL) and case-insensitivity, exceeding schema's 'Coin ticker.'. Value added beyond schema.
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 'Get spread and liquidity analysis for a Hyperliquid perpetual' with specific output fields (bid-ask spread, estimated slippage at $10k/$50k/$100k/$500k, liquidity score). Verb 'get' plus resource differentiate from sibling tools.
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?
Implied usage: use when spread/liquidity data needed. No explicit when-not-to-use or comparison to siblings like cerebrus_basis or cerebrus_health. Could benefit from context on when this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool is free and returns tickers for 30+ coins, implying it's a read-only operation with no side effects. Although it doesn't mention rate limits or authentication, these are not likely needed for a free list tool.
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 two sentences long, front-loaded with the main action, and free of unnecessary details. Every sentence adds value.
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?
For a simple list tool with no parameters and no output schema, the description provides sufficient context: what it returns (tickers for 30+ coins) and that it's free. No additional information is needed.
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 has zero parameters, so the description correctly adds no parameter details. Per guidelines, 0 parameters yields a baseline of 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 lists all available coins on Cerebrus Pulse and returns tickers for 30+ Hyperliquid perpetuals. This verb-resource combination is specific and distinguishes it from sibling tools which focus on specific metrics like basis or funding.
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 mentions 'FREE — no payment required,' which implies it can be used without cost and suggests it's a basic utility tool. While it doesn't explicitly state when not to use or provide alternatives, the context from sibling names makes it clear this is for general listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It discloses the paid nature ($0.02), the read-only operation (Get), and aggregation details (daily/weekly from 1h). It does not mention rate limits or authentication, but given the read-only, paid nature, the description is fairly transparent. The cost is a key behavioral trait.
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 a single sentence that packs in the tool's purpose, supported timeframes, all returned indicators, data types, and cost. Every part is informative with no redundancy or filler. It is front-loaded with the primary action and resource.
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 having no output schema, the description enumerates all key return values (RSI, EMAs, ATR, Bollinger Bands, VWAP, Z-score, trend direction, cross-timeframe confluence, derivatives data, market regime) and the cost. This provides a complete picture of what the tool returns, sufficient for an AI agent to decide whether to invoke it.
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 listing all 6 supported timeframes (5m, 15m, 1h, 4h, 1d, 1w) and noting the default ('1h,4h'). It also clarifies that coin is case-insensitive, reinforcing the schema. This goes beyond the schema's description of timeframes as a comma-separated string.
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 specifies the verb 'Get', the resource 'multi-timeframe technical analysis', and the scope 'for a Hyperliquid perpetual'. It lists supported timeframes and key indicators, and distinguishes from siblings like cerebrus_funding (funding rates) and cerebrus_basis (basis) by focusing on comprehensive technical analysis.
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 states the cost ($0.02 USDC via x402), which serves as a usage constraint. It implies the tool is for technical analysis of Hyperliquid perpetuals, but does not explicitly mention when not to use it or suggest alternatives among siblings. The list of indicators provides context for when to use it, but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cost ($0.01 USDC via x402), which is valuable behavioral info. No annotations exist, so description carries burden. Does not mention auth or rate limits, but cost is a key trait.
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, each earning its place: first defines purpose, second adds essential cost detail. No extra 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?
With zero parameters and no output schema, the description thoroughly explains the tool's output and constraints. Complete for expected usage.
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 has 0 parameters (100% coverage), baseline 3. Description adds context on return values and cost, exceeding baseline by providing additional meaning.
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 verb 'Get' and resource 'aggregated crypto market sentiment analysis', and specifies what is returned. It distinguishes from siblings by explicitly noting 'Not coin-specific'.
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?
Provides context on when to use by stating 'Not coin-specific', implying use for overall sentiment. Lacks explicit alternatives or when-not-to-use, but sibling names offer differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![cerebrus-pulse-mcp MCP server](https://glama.ai/mcp/servers/0xsl1m/cerebrus-pulse-mcp/badges/card.svg)](https://glama.ai/mcp/servers/0xsl1m/cerebrus-pulse-mcp)

Score Badge

Copy to your README.md:

[![cerebrus-pulse-mcp MCP server](https://glama.ai/mcp/servers/0xsl1m/cerebrus-pulse-mcp/badges/score.svg)](https://glama.ai/mcp/servers/0xsl1m/cerebrus-pulse-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/0xsl1m/cerebrus-pulse-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server