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

Annotations already declare this a read-only, idempotent, non-destructive closed-world call, so the safety profile is covered. The description adds genuinely useful interpretation guardrails beyond that: relative chart emphasis is not a favorable-outcome score or probability, and equal scores do not indicate a better date. Those caveats shape how an agent should present results and are not derivable from structured fields.

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 opening sentence front-loads what the tool returns, followed by access-mode conditions and then the interpretation caveats, which is a sensible order. Nearly every sentence earns its place, though the 'sampled Calendar contacts' clause is vague enough to read as filler rather than signal.

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?

An output schema exists, so return values need not be described, and the description covers access modes, scope limits, and score interpretation. What remains thin is precisely how dates are evaluated relative to each other and what 'relative chart emphasis' means in practice, but for a three-parameter read tool this is close to complete.

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 coverage at 67%, the description usefully reinforces the 1-8 date cap and explains selection semantics the schema only partly covers: a supplied chartContext selects the temporary chart, an absent value selects the authorized saved self chart, and temporary charts require a timezone when their context lacks one. It stops short of clarifying date interpretation (e.g., civil-date vs. local time) beyond the schema's format pattern.

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 a specific verb and resource: a comparison of one to eight distinct civil dates from the same personal chart plus sampled Calendar contacts. That scope clearly separates it from siblings like get_daily_focus or get_timing_month, but the phrase 'sampled Calendar contacts' is left unexplained and could confuse an agent about what data is actually compared.

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 gives prerequisites (temporary chartContext with a confirmed timezone vs. the authorized saved self chart with full_timing access) and an exclusion ('Excludes saved events and conversations'), which implies usage context. However, it never states when to pick this over get_daily_focus, get_timing_month, or get_timing_year, so the agent must infer the boundary itself.

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