Market Profile: daily TPO profile of a perpetual, point of control, value area, initial balance, naked POCs

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover readOnly and openWorld, so the bar is lower, but the description adds substantial behavioral context: it discloses the data source (own one-minute bars of Binance USDT-M perp), calculation parameters (30-min TPO periods, 0.05% buckets, 70% VA, first-hour IB), scope (one row per closed UTC day), and an edge case (symbols without minute bars return no_profile). It does not discuss latency or rate limits, hence a 4 rather than 5.

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?

Two sentences, front-loaded with the trigger condition, but the second sentence is a dense, comma-laden inventory of return fields that is hard to parse. The value-area abbreviations (VAH, VAL) are expanded, which helps, yet the run-on structure reduces readability.

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 read-only data-retrieval tool with no output schema, the description adequately conveys what is returned (daily profile rows, naked POCs, latest day per bucket) and includes an important edge-case behavior (no_profile). It is complete enough for correct invocation, though a note on pagination or time-to-compute would make it fully self-contained.

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 100% and the schema documents both parameters with defaults, ranges and a symbol pattern. The description adds meaning for the data window indirectly ('closed UTC day', 'last 60 recorded days') but doesn't restate or refine the 'days' parameter semantics. Baseline 3 is appropriate when the schema carries the parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (returns Market Profile data for a perpetual) and enumerates the exact metrics: TPO profile, POC, VAH/VAL, initial balance, naked POCs. Distinguishes clearly from siblings like get_orderbook_depth or get_volume_profile-adjacent tools by naming its unique concepts.

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?

Front-loads 'Call this when the user asks about...' with a rich set of trigger terms (Market Profile, TPO, POC, value area, initial balance, naked POC), which is strong contextual guidance. However, it does not name sibling alternatives (e.g., where to go for raw price/volume) or state exclusions, so it stops short of full when/when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.