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

No annotations are provided, so the description carries the full disclosure burden. It usefully states that counts, total market value, and estimated annual tax recovery recalculate in real-time, but says nothing about the mutation consequences of remove/toggle, whether curation is persisted or reversible, what "auto" or the opaque "TypeSafe System One (Jev)" actually does, or any auth/rate constraints — a significant gap for a state-changing tool.

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?

Two dense sentences, front-loaded with the core action and followed by the recalculated outputs. Every clause maps to a capability or side effect. Minor cost: the inline jargon "TypeSafe System One (Jev)" adds a name the agent cannot act on.

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 7-parameter, state-mutating tool with no annotations and no output schema, the description covers the action surface and the derived recalculations reasonably. It does not explain the return payload, what happens to the staged list after remove/toggle, or how it composes with stage_portfolio_selection, leaving a real gap for correct invocation.

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 100%, so the baseline is 3, but the description genuinely adds meaning beyond the enum labels: it maps 'add'/'remove' to domain intent (new parcels vs. sold or NNN properties), 'set_homestead' to Primary Residence/Homestead HQ, and 'auto' to natural-language execution. It still leaves staging_id, client_name, and reason semantics entirely to the schema.

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?

Specific verb+resource ("curate a staged portfolio selection") with an enumerated action set: add parcels, remove sold/NNN properties, toggle, set Primary Residence/Homestead HQ, and NL execution. An agent knows exactly what the tool does. However, it never distinguishes itself from the closely-named sibling stage_portfolio_selection, so an agent must infer that this operates on an already-staged set rather than creating one.

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?

Usage is implied by "from previous staging/curation turn" in the schema and by "staged portfolio selection in Chat / MCP," suggesting it is a follow-on to staging. But there is no explicit when-to-use statement, no exclusion of stage_portfolio_selection or check_portfolio_address_status, and no prerequisite that a staging_id must already exist.

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