[marketsummary] Real move or just the majors? Market breadth over our tracked crypto set.
Free = advance/decline (how many up vs down today). Premium = + the 1h intraday pulse (freshest read) + relative-strength breadth (how many lead vs lag BTC). Breadth of OUR tracked set, not the whole market; stated as such. Not financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| payment | No | ||
| session_token | No |
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 disclose the free vs. premium data difference and the scope limitation ('breadth of OUR tracked set'), which adds valuable context. However, it omits any explicit statement about read-only nature, authentication requirements, or potential errors, and does not describe the output format or pagination.
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 reasonably concise and front-loaded with a purpose-defining question. It includes necessary information about free vs. premium and scope, but the closing 'Not financial advice' disclaimer and the rhetorical question add slight verbosity without contributing to tool invocation. Overall, it is well-structured but not maximally tight.
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 gives a clear conceptual overview and differentiates free/premium offerings, but it lacks details about the output structure, the purpose of session_token, and any prerequisites or error conditions. Without an output schema and annotations, these omissions make the tool less complete than it could be for an agent to use confidently.
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 has 0% description coverage, so the description must compensate. It partially explains the 'payment' parameter through the free/premium distinction, but the 'session_token' parameter is never mentioned or explained. This leaves a significant gap in understanding how to invoke the tool correctly.
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 that the tool provides 'market breadth over our tracked crypto set' and distinguishes between free (advance/decline) and premium (intraday pulse and relative-strength) tiers. The opening question 'Real move or just the majors?' frames the intent, and the explicit scope note ('not the whole market') differentiates it from other market-wide tools like get_market_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 a clear use case: when you want to know if a market move is broad or concentrated in major coins. It provides context about comparing broad market participation, but it does not explicitly mention when not to use the tool or name alternative tools for similar queries, leaving some ambiguity for agent selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct metric or action: attention shifts, buzz score, trending, and narrative tracking measure different facets; longs, shorts, and setups use different strategies; market regime, breadth, and summary are clearly separated. No two tools appear to produce the same output.
All tools follow a consistent pattern: a subsystem prefix (marketsummary__, tokensafety__, verify__) followed by an imperative verb_noun in snake_case. Verbs are predictable (get, find, track, ask, check, request, verify) and objects are clear, making the naming highly uniform.
24 tools is above the typical 3-15 range, but the server covers a broad market-intelligence domain with distinct feature areas. The tools are namespaced by subsystem, which helps agents navigate, but the volume still adds selection overhead.
The set covers market analysis, trending, sentiment, trade setups, token safety, and wallet verification for premium access. Minor gaps exist (e.g., no direct price/OHLC tool or token search), but agents can work around them using the provided tools.