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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It reveals the outlier-removal algorithm (modified Z-score over MAD when n≥4), the conditional yearRange/hasStaleData output tied to estimateYear, and the exact output composition including the agreement-score definition. This gives the agent an accurate mental model of the computation and its edge cases.

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 three dense sentences with no filler. The first sentence states the purpose and input condition, the second covers the optional parameter effect, and the third explains the algorithm and return values. Every clause contributes new, actionable 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?

Since there is no output schema, the description appropriately enumerates all return components: extracted dollar amounts, consensus median, agreement score, and the optional yearRange/hasStaleData fields. It also defines the agreement score and covers the key algorithmic edge case (outlier handling only when n≥4), making the tool callable and interpretable without further documentation.

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 is the primary source of parameter meaning. It clarifies that the input objects are 'sources of market-size text,' that 2-3 such sources are expected, and that estimateYear controls the yearRange and hasStaleData output fields. This is far more informative than the bare schema, which only names source, text, and estimateYear without describing their role.

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 opens with 'Multi-source TAM consensus,' a specific verb-plus-resource statement that clearly identifies the tool's job: aggregating market-size estimates from multiple text sources. The TAM focus cleanly distinguishes it from the 20 sibling compute_* tools, which address unrelated signals like budget proof, social pain, or funding momentum.

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 explicitly states the expected input volume ('Pass 2-3 sources of market-size text') and explains when the optional estimateYear parameter is relevant, giving an agent a clear invocation context. It does not name alternatives or state when not to use the tool, 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.