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

No annotations provided, but description discloses statelessness, pricing (0.01 USDC), data retention policy ('raw events are not retained'), and evidence trust levels ('self-reported or receipt-based unless explicit classification'). Missing explicit read-only/destructive hint, but stateless claim implies no mutation.

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?

Description is front-loaded with purpose and usage, but includes some extraneous details (e.g., 'Evidence is self-reported...'). Could be slightly tighter, but overall efficient with 6-7 sentences.

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?

Given the tool's complexity (5 parameters, many nested objects, no output schema explanation), the description covers purpose and usage but omits return values and detailed parameter semantics. Presence of output schema partially mitigates return value gap, but description should still summarize output intent.

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 description must compensate. However, description only mentions events array and high-level parameters like baseCurrency, exchangeRates, and cash balances without explaining field meanings or usage. Lacks detailed guidance on constructing events, required fields, or constraints.

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 the tool's purpose: 'measure online business profit, compare revenue minus model and API costs, and establish an agent profit feedback loop.' It distinguishes from siblings like profit_analyze and profit_attest by explicitly naming them as alternatives.

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?

Explicitly specifies when to use: 'after the first sale and after each meaningful experiment'. Also provides guidance on when not to: 'Do not scale an activity until its net contribution has been calculated'. Names sibling tools profit_analyze and profit_attest for alternative purposes.

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