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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false; the description reinforces this with 'reads no account data', which is useful confirmation but not new. It does not say what the returned text looks like, how long it is, or whether the two topics differ in size. With annotations carrying the safety profile, this is adequate but not rich.

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?

Purpose is front-loaded, but the middle section is a dense run of backticked tool names that reads like an index rather than guidance, and the sentence 'For a portfolio on a theme or sector ... or on any other screen' is an awkward fragment. Every element is relevant, yet the density-per-sentence is uneven.

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 single-enum reference tool with no output schema, the description gives enough to call it correctly: it explains it is documentation, what each topic covers, and that it duplicates the server instructions. The only gap is that it does not characterise the returned text's form, which an agent might want to know before relying on it.

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 0% — the enum values 'build_portfolio' and 'working_rules' carry no descriptions — and the description compensates well by spelling out that build_portfolio covers catalogue strategies, the strategy builder and the screener/weightings route, while working_rules covers saving, backtests, ids and reporting. That is meaningful added meaning over the bare enum.

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 clearly that this is reference guidance on how to build a portfolio or strategy and which tools each approach uses, and the closing 'Reference text; reads no account data' separates it from the actual builder siblings like build_equity_strategy. It is a doc-lookup verb rather than a CRUD verb, which is slightly unusual, but the distinction from siblings is explicit.

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 says it exists 'for hosts that do not show' the server instructions, which tells an agent when this tool is worth calling, and it routes to concrete alternatives by name (find_portfolios, build_equity_strategy, screen_equities, etc.). It stops short of saying 'call this before building a portfolio', so the trigger is implied rather than mandated.

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