basis

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

With no annotations, the description carries the whole behavioral burden. It does disclose one genuinely useful trait, the ASOF join onto the nearest prior print, which tells the agent how the two legs are aligned in time. But it says nothing about the return shape, ordering, units, or cost, so the disclosure is partial rather than complete.

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?

One front-loaded sentence with zero filler, and the join semantics come first. It is arguably too terse for the tool's complexity, but there is no structural waste and no buried information.

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?

This is a five-parameter tool with no annotations and no output schema, so the description must do the work. It does not say whether the result is a time series or a single value, what the basis unit is, how many rows come back, or what a missing prior print yields. Only the join rule is covered, leaving large gaps for the agent to fill.

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?

Per-property description coverage is low (only asset_class is described inline), so the description needs to compensate. The struct-level prose in the schema does explain that perp_symbol is the derivative leg (a future for equities) and that start_ns/end_ns are a required window, which covers the most error-prone fields. However, the description supplies nothing on the symbol or window parameters itself, and much of the struct prose is design rationale rather than caller-facing meaning.

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 one-liner does say what is being computed: the spread of spot against the perpetual mark. But it never names a verb (compute/derive) or the output form, and it gives no signal for choosing between it and the near-identical sibling names perp-basis and spot-future-basis. An agent sees the resource but must open the schema and guess at the sibling distinction.

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 contains no when-to-use, no prerequisites, and no alternatives, even though perp-basis, spot-future-basis, and term-structure all overlap heavily. Nothing tells the caller whether this is the right tool or how it differs from those siblings. It is not misleading, but it provides no routing guidance at all.

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