sotp_valuation

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

Annotations already establish this as read-only and idempotent, and the description is fully consistent. Beyond the annotations, it discloses the tool's key behavioral boundary — it computes but does not judge — and explains the expected analyst contribution: reasoning per segment, supplying rationale, and marking the output as an AI interpretation. This is materially useful context.

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 dense but every sentence carries important information: mechanics, usage context, a real-world example, and analyst responsibilities. It could be slightly tightened or broken into bullets, but it remains well front-loaded with the core function and does not waste words on filler.

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 valuation tool with no output schema, the description covers the full workflow: valuation logic, segment structure, citation of peer inputs, rationale expectations, and metadata handling. An agent has enough to call the tool correctly and to present the result appropriately in a report.

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?

With schema description coverage at 0%, the description compensates well: it enumerates the allowed metric types, clarifies that 'Direct EV' supplies the segment value directly while other metrics use a multiple, and traces how cash, netDebt, and sharesOutstanding feed into the final per-share value. companyName is not explicitly mentioned, but its meaning is self-evident, so the gap is minor.

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 a specific verb and resource: 'Runs a Sum-of-the-Parts valuation,' then walks through the exact valuation waterfall. It also distinguishes itself from a single blended DCF/multiple by stating it is for companies whose segments have genuinely different economics, which separates it from dcf_valuation and comparables_valuation siblings.

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?

It explicitly says when to use this tool ('Use this instead of a single blended DCF/multiple for a company whose segments have genuinely different economics') and gives a concrete example. It also tells the agent what not to expect ('does NOT choose the multiples for you') and directs it to peer-comparison tools for support, making the selection and invocation decision clear.

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