Nine chain onchain intelligence with a verifiable onchain signal attestation stream
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.6/5 across 11 of 11 tools scored. Lowest: 2.9/5.
Each tool targets a distinct metric—attestation stats, congestion, correlation, IV, market state, MEV, proof spec, session stats, reveals, verification, and whale flows—with no overlapping purposes. An agent can easily select the right tool for a specific intel need.
All tool names use lowercase_snake_case, but most are noun_noun (e.g., attestation_stats, market_state) while a couple are verb_noun (list_reveals, verify_reveal) and one is just a noun (congestion). The pattern is mostly consistent and predictable despite minor deviations.
With 11 tools, the server is well-scoped for a blockchain intel analytics domain. Each tool provides a distinct data product, making the set comprehensive without feeling bloated.
The tool surface covers the core attestation lifecycle (stats, reveals, verification, and spec) as well as a broad range of market analytics (congestion, correlation, IV, regime, MEV, sessions, whale flows). No obvious gaps or dead ends exist for the stated purpose.
attestation_statsAInspectLive counts of the attestation stream: committed, anchored, revealed, gaps
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| gaps | Yes | |
| anchors | Yes | |
| revealed | Yes | |
| committed | Yes | |
| latestSeq | Yes | |
| awaitingMaturity | Yes | |
| revealDelayHours | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a read-only query via 'live counts', but does not explicitly state that the tool is side-effect-free, what 'live' means (e.g., real-time polling vs. snapshot), or whether any special access is required. The description gives basic behavioral context but lacks richer detail.
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 description is a single, front-loaded sentence that says 'Live counts' first, then expands with a colon-delimited list of specific metrics. Every word contributes value, and the structure is highly scannable. It is an model of conciseness for a simple tool.
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?
Given the tool has no inputs, an output schema explains return fields, and the tool is a straightforward read-only stats endpoint, the description adequately explains what data is provided. It lacks timing or usage context (e.g., relationship to session_stats), but for its simplicity, it is reasonably complete. The absence of usage guidelines is a minor 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 tool has zero parameters and the input schema is empty, so the description correctly adds no parameter specifics. According to the rubric, the baseline for 0-param tools is 4, and the description introduces no confusion about inputs. It is inconsequential that no parameter details are provided.
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 clearly states the tool provides 'Live counts of the attestation stream' and enumerates specific categories (committed, anchored, revealed, gaps), making its function unmistakable. It also distinguishes itself from sibling tools like whale_flows or congestion by focusing on attestation-specific metrics. Though not using a leading verb like 'get', 'counts' effectively conveys the action.
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 offers no guidance on when to use this tool versus alternatives. It does not mention any specific use cases, prerequisites, or exclusions relative to sibling tools. Without a when-to-use section, an agent has little basis for selecting this over other stats tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
congestionAInspectRequires a ChainHelix API key as bearer token, or 2 cents in USDC per call paid over x402 on the Base network. Bitcoin queue depth and fee level now vs the past 30 days
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| p90_30d | Yes | |
| median30d | Yes | |
| fastestFee | Yes | |
| pendingTransactions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the auth method (ChainHelix bearer token) and cost (2 cents USDC via x402), which are important behavioral traits. However, it doesn't explicitly state read-only status or side effects, but the nature of the data suggests a safe query.
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 description is a single sentence, very concise. However, the ordering is suboptimal: payment requirements are placed before the core purpose. Still, no redundant words, and the structure is easy to parse.
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 an output schema present, return values are covered. The description includes the essential access method and the data scope (current vs 30-day history). It could clarify 'queue depth' but this is implied. Overall, sufficient for a simple zero-parameter tool.
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, and the schema is empty, so the baseline is 4. The description adds no parameter details because none exist, which is acceptable.
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 clearly states the tool provides Bitcoin queue depth and fee level now vs the past 30 days. This is a specific verb (provides/comparison) and resource (Bitcoin congestion metrics), distinguishing it from sibling tools like market_state or whale_flows.
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 tool vs alternatives. The description only mentions payment/auth requirements and what data it returns, but does not indicate scenarios or exclusions relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
correlation_matrixAInspectRequires a ChainHelix API key as bearer token, or 2 cents in USDC per call paid over x402 on the Base network. Pairwise correlation of hourly returns across the nine chains. window in days default 7 max 30
| Name | Required | Description | Default |
|---|---|---|---|
| window | No |
| Name | Required | Description |
|---|---|---|
| mean | No | |
| pairs | Yes | |
| windowDays | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses authentication/payment requirements and parameter bounds ('window in days default 7 max 30'), adding behavioral context beyond the schema. With no annotations, these details are valuable, though it does not explicitly label side effects (likely read-only).
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?
Three concise sentences cover purpose, access, and parameter constraints with no redundancy or filler.
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?
Includes purpose, data scope (nine chains), access methods, and parameter constraints. With an output schema present and only one optional parameter, the description is sufficient for an agent to invoke correctly.
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 schema provides only a 'window' field with no description; the description adds meaning by specifying unit (days), default (7), and maximum (30), fully compensating for zero schema coverage.
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?
Description states 'Pairwise correlation of hourly returns across the nine chains' – a specific computation over a defined data scope, clearly distinct from sibling tools like market_state or mev_intel.
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?
Provides clear context for use (computing return correlations) and access requirements (API key or x402 payment), but does not explicitly compare with alternative tools; thus clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
iv_summaryBInspectRequires a ChainHelix API key as bearer token, or 2 cents in USDC per call paid over x402 on the Base network. Near term option implied volatility for Bitcoin and Ethereum, now vs one week ago
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It does disclose the need for a ChainHelix API key or USDC payment over x402, which is a significant access constraint. It also indicates a time comparison ('now vs one week ago'). However, it lacks details on output format, rate limits, or read-only nature, though an output schema exists.
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 description is concise with two sentences. The first sentence states required authentication/payment, which is useful but placed before the purpose. The second sentence states the data content. It is efficient and not verbose, though front-loading the purpose would be marginally better.
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?
Given the tool's simplicity (0 parameters) and the existence of an output schema, the description covers the essential subject matter and access requirements. It does not need to explain return values due to the output schema. The only gap is lack of usage guidance, which is already penalized in dimension 2.
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 no parameters, so the schema coverage is trivially 100%. Per the baseline for 0 params, the description need not explain any parameter semantics. The description incidentally clarifies what data the tool returns, which is sufficient.
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 phrase 'Near term option implied volatility for Bitcoin and Ethereum, now vs one week ago' clearly identifies the resource and the comparison being made. It lacks an explicit verb like 'retrieves' or 'shows', but the intent is unambiguous and distinct from sibling tools which cover different topics.
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 guidance on when to use this tool versus alternatives. The description only states authentication/payment requirements, which is not usage context for decision-making. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_revealsCInspectMatured signal reveals with Merkle paths. Optional month YYYY-MM and limit
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| month | No |
| Name | Required | Description |
|---|---|---|
| month | No | |
| latest | No | |
| months | No | |
| reveals | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses only the output content (matured reveals, Merkle paths) but lacks details on side effects, read-only behavior, defaults, or limitations. This is insufficient for a tool with no annotation support.
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 description is a single concise sentence, front-loaded with the core purpose. It is efficient but slightly cryptic, potentially sacrificing clarity for brevity.
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?
While an output schema exists, the description lacks domain context: what 'matured' means, how month/limit affect results, and how this tool fits with siblings. Minimal information for correct invocation in an unfamiliar domain.
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?
Schema coverage is 0%, so the description compensates partially by specifying month format (YYYY-MM) and noting both parameters are optional. However, it does not clarify what 'limit' controls or how 'month' filters results, leaving ambiguity.
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 'Matured signal reveals with Merkle paths' clearly indicates the tool lists reveals that have matured and includes Merkle paths. Though the verb is implied, the tool name 'list_reveals' and the noun phrase convey purpose distinctly from sibling tools like 'verify_reveal'.
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 explicit guidance is given on when to use this tool versus alternatives. It mentions optional parameters but does not provide context for selecting this over siblings such as attestation_stats or verify_reveal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_stateBInspectRequires a ChainHelix API key as bearer token, or 2 cents in USDC per call paid over x402 on the Base network. Regime, range age and volatility state per chain. Omit chain for all nine
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses authentication methods (bearer token or x402 payment) and the behavior of omitting chain to get all nine chains. However, it does not explicitly state that this is a read-only operation or mention any rate limits, caching, or side effects. The disclosure of payment/auth is useful, but more behavioral context is needed.
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 description is brief (two sentences) and conveys necessary information without padding. However, the first sentence is about requirements rather than the main purpose, and the structure could be improved by leading with the core function. Still, it is concise and readable.
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?
The tool has a simple one-parameter schema and an output schema, so the description need not explain return structure. It covers what data is returned (regime, range age, volatility), how to request all chains, and the auth/payment requirements. It lacks mention of data freshness or error scenarios, but given the output schema, this is reasonably complete.
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?
Schema coverage is 0%, so the description must compensate. It effectively explains the 'chain' parameter by stating that omitting it returns all nine chains, which is crucial default behavior not evident from the schema alone. The enum values are self-documenting, but the optionality and default are clarified.
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 the tool provides 'Regime, range age and volatility state per chain,' which clearly indicates a market state query. The verb is implicit rather than explicit, but the resource and scope are clear. It distinguishes from siblings by focusing on market state rather than congestion, correlation, or IV.
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 gives authentication/payment prerequisites and a parameter usage rule ('Omit chain for all nine'), but it does not explain when to use this tool versus alternatives. No explicit when-to-use, exclusions, or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mev_intelBInspectRequires a ChainHelix API key as bearer token, or 2 cents in USDC per call paid over x402 on the Base network. MEV event rates per chain and type vs the trailing weekly pace. window in hours, default 24, max 168
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | ||
| window | No |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal important operational details: a required ChainHelix API key or a per-call payment of 2 cents USDC via x402, and the window parameter's range/default. However, it does not explicitly state whether the operation is read-only, nor does it cover rate limits or response behavior beyond the raw rates. The disclosed auth and cost constraints add meaningful context, but some behavioral aspects remain implicit.
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 description is compact, consisting of two sentences that cover requirements and functionality without extraneous detail. The front-loading is slightly suboptimal: the first sentence focuses on authentication/payment rather than the core purpose, which might delay clarity. Nevertheless, every sentence carries necessary information, and there is no wasted 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?
Given the low complexity (2 optional params, output schema present), the description is largely complete: it explains auth, payment, the data provided, and the temporal window constraints. It does not explicitly state whether 'chain' is optional or which event types are included, but the schema's enum and output schema fill those gaps. Overall, an agent can reasonably understand how to invoke the tool and what to expect.
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?
Schema description coverage is 0%, so the description must compensate. It explicitly specifies the 'window' parameter's unit (hours), default (24), and maximum (168), which the schema does not convey. It also clarifies that the tool reports rates 'per chain and type,' indirectly describing the 'chain' parameter as a filter. This adds significant value beyond the bare schema definition, though the chain enum values are left to the schema.
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 centers on 'MEV event rates per chain and type vs the trailing weekly pace,' which clearly identifies the resource (MEV rates) and the analytical comparison. It does not include an explicit verb like 'returns' or 'lists,' but the context strongly implies a data-query tool, and it distinguishes itself from siblings such as congestion or correlation_matrix. Minor ambiguity exists because the core sentence is a noun phrase rather than a full actionable statement.
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 is provided about when to use this tool versus available alternatives (e.g., market_state, whale_flows). The description only mentions authentication and payment requirements, not use cases or exclusions. The phrase 'MEV event rates' implies a specific data need, but there is no explicit 'use when' statement or comparison to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
proof_specCInspectThe machine verification spec for the ChainHelix attestation stream
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description itself must disclose behavior, but it only says what the spec is, not what the tool does (e.g., returns, validates, or generates it). It does not mention read-only status, return format, or any side effects, leaving the agent without critical behavioral information.
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 description is a single, tightly worded sentence with no redundancy. It effectively front-loads the core subject and includes the key context of ChainHelix attestation stream, making it concise and free of wasted words.
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?
Despite the tool's simplicity (0 params, output schema exists), the description still fails to explicitly state that invoking it returns the specification. It does not clarify the operation, safety, or any limitations. An explicit verb like 'Returns' would make it complete for this minimal tool.
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 input schema has zero parameters, so schema coverage is trivially 100%. The baseline for 0 parameters is 4, and the description does not need to explain inputs. It adds no parameter-related meaning, but none is necessary.
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 identifies a resource ('machine verification spec') and specifies a domain ('ChainHelix attestation stream'), but it lacks an explicit action verb. The tool name suggests it might return or define the spec, but the purpose remains ambiguous because it does not state what the tool does with the spec.
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 guidance on when to use this tool or how it relates to sibling tools such as verify_reveal or iv_summary. The description provides no context for selecting it over alternatives, offering only a static noun phrase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
session_statsAInspectRequires a ChainHelix API key as bearer token, or 2 cents in USDC per call paid over x402 on the Base network. Share of price movement per trading session over 7 days. Sessions are Asia London New York in UTC thirds
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the payment/auth requirement (ChainHelix API key or USDC via x402). It also clarifies the session definitions. However, it does not explicitly state whether the operation is read-only or mention other behavioral traits like 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 description is concise at roughly three sentences, but the payment information is presented before the core purpose, slightly obscuring the main functionality. It is still efficient and avoids redundancy.
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 tool with one optional parameter and an output schema, the description covers the core output (share of price movement per session) and defines the sessions. The missing explanation of the 'chain' parameter is a minor gap, but overall the description is fairly complete for the tool's simplicity.
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 description does not mention the 'chain' parameter at all. With 0% schema description coverage, the agent must rely solely on the enum values (e.g., bitcoin, ethereum) to infer meaning. The description adds no explanation of how the chain parameter affects the output.
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 clearly states the tool provides the share of price movement per trading session over 7 days, with explicit session definitions (Asia, London, New York in UTC thirds). This specific and resource-focused description differentiates it from sibling tools like market_state or iv_summary.
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 implies usage when you need session-level price movement breakdown but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. No sibling tools are referenced for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_revealAInspectRecompute the hash and Merkle fold for one reveal by sequence number. Returns each check result plus the data to re-verify independently on chain
| Name | Required | Description | Default |
|---|---|---|---|
| seq | Yes |
| Name | Required | Description |
|---|---|---|
| note | No | |
| found | Yes | |
| status | No | |
| opbnbTx | No | |
| anchorBscTx | No | |
| verifyOnChain | No | |
| hashRecomputes | No | |
| merkleFoldsToAnchorRoot | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool returns each check result plus data for independent on-chain verification, implying a read-only verification operation. It does not mention permissions or error cases but gives useful behavioral context beyond the bare action.
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 description is two concise sentences, front-loaded with the action and immediately followed by the return value. No unnecessary words or repetitions, every sentence earns its place.
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?
The description covers purpose and output, and the output schema exists so return details are not required. It conveys the verification workflow well, though it doesn't mention prerequisites (e.g., reveal must exist) or error behavior, which are minor for a read-only verification tool.
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 parameter seq is implied as 'sequence number' in the description, but there is no additional detail beyond the schema (type number, required). Since schema coverage is 0%, the description partially compensates but remains minimal, just naming the identifier type.
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 clearly states the tool recomputes the hash and Merkle fold for a reveal by sequence number. Uses specific verb 'recompute' with a clear resource and scope, distinguishing it from sibling tools like list_reveals or mev_intel.
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 context is clear: use this tool to verify a specific reveal by sequence number. No explicit alternatives or exclusions, but the focused scope is evident. Sibling tools are mostly stats or flow related, so separation is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whale_flowsCInspectRequires a ChainHelix API key as bearer token, or 2 cents in USDC per call paid over x402 on the Base network. Large transfer counts and USD totals per chain. window in hours default 24 max 168, threshold 500000 USD
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | ||
| window | No |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses authentication/payment requirements and parameter constraints (window default/max, threshold), which is useful. However, it does not clarify whether the operation is read-only or describe error/rate-limit behavior.
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 description is short and all sentences carry relevant information (auth, output hints, and parameter details). The third sentence is grammatically fragmented but still efficient.
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?
The tool has an output schema, so return structure is covered. The description covers auth, payment, defaults, and a threshold, but lacks an explicit purpose statement and usage context. It is adequate for a low-complexity tool.
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?
Schema coverage is 0%, so the description must compensate. It explains window's default and max value, adding meaning beyond 'number'. Chain is already self-descriptive via the enum. The threshold is mentioned but is not a parameter, causing slight confusion.
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 mentions 'Large transfer counts and USD totals per chain', which implies the tool returns data about large transfers, but it lacks a clear verb like 'get' or 'list'. It does not explicitly differentiate from sibling tools such as mev_intel or congestion.
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 guidance on when to use this tool compared to alternatives. It only provides payment and parameter details, not context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!