mass_mapBounded MASS scan. Select exchanges with comma-separated venues. Rows stay separate. Pro key required.
| Name | Required | Description | Default |
|---|---|---|---|
| coins | No | ||
| limit | No | ||
| venues | No | ||
| impact_pct | No | ||
| venue_class | No | perp |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It discloses a few traits: the scan is bounded, venues are selected with comma-separated values, rows remain separate, and a Pro key is required. However, it does not clarify what 'bounded' refers to, whether the operation is read-only, rate limits, error behavior, or the nature of results, leaving notable ambiguity for an agent.
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 and front-loaded, with no filler words. Each sentence conveys a fact, and the formatting is scannable. It loses one point because the terse wording contributes to ambiguity, so it is not perfectly structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, five undocumented parameters, and no parameter descriptions in the schema, the description is insufficient. It omits details about what each parameter controls, what the output looks like, and how this tool relates to the sibling mass_scan. The presence of an output schema does not compensate because its structure is not provided. Overall, the agent lacks essential information for confident use.
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%, leaving the description to compensate. It only explains the venues parameter (comma-separated format). The meanings of coins, limit, impact_pct, and venue_class are entirely absent, and even the relationship between 'bounded' and the limit parameter is not explicitly stated. Five unexplained parameters at zero coverage are not adequately addressed.
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 'Bounded MASS scan' and mentions venue selection and row separation, but it never states what output the tool actually produces or what 'MASS' signifies. It is clear enough to separate it from generic tools, yet it fails to distinguish it from sibling mass_scan or to define the core resource being acted on.
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 on when to use this tool versus alternatives like mass_scan, market_snapshot, or market_rotation. The only contextual note is 'Pro key required', which is an access restriction rather than a usage guideline. There is no statement of conditions that would favor mass_map over a sibling.
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.
Most tools target distinct analytics functions (order flow, execution cost, strategy testing, market scans). A few pairs overlap—mass_map/mass_scan, market_rotation/top_movers, and market_snapshot/perp_dashboard—but descriptions clarify differences. No tools are truly indistinguishable.
Naming style is mixed: some tools use verb+noun (explain_move, fetch_series, get_funding) while others use descriptive noun phrases (carry_pressure, currency_leg, exit_capacity). The names are readable and meaningful, but the pattern is not uniform. It is not chaotic, but lacks a single consistent convention.
22 tools is on the heavier side but reasonable for a comprehensive crypto analytics suite covering market data, execution analysis, risk, and strategy testing. Each tool serves a distinct purpose and contributes to the overall scope. It is not excessive enough to feel bloated.
The tool set covers the full analytics lifecycle: market overview, order-flow explanation, execution routing and cost, position limits, options, and strategy backtesting. There are no obvious dead ends; users can research, test, and validate strategies. The coverage is thorough for the stated trading-analytics domain.