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

Annotations already establish readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered; the description still adds real behavior beyond that: nothing is spent, the quote reads ask and content only for screening and the minutes estimate, it never fetches a content URL, and it does not persist input. It also discloses the pay default (0.00) and the $18-an-hour floor. This is substantive disclosure, though the description leans heavily toward the commercial model rather than the operational one.

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 key safety fact ('nobody is rung and nothing is spent') is front-loaded, and the trailing example is high-value for a 19-param schema. Some parenthetical asides ('the quote is priced from minutes', the repeated pay-default clause) are denser than needed, but nothing is padding.

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?

Return values are enumerated (per-line pricing, total_usd, expected_minutes_to_enough, test_money, for_your_user) even though an output schema exists, which is mildly redundant but useful for the display-sentence guidance. For a nested 19-parameter tool with zero schema documentation, however, several decision-relevant fields remain unexplained, so the definition is helpful but not sufficient on its own.

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 19 parameters and 0% schema description coverage, the description must carry the full load, and it only partly does: it clarifies content (omit until the user supplies material), pay (default 0.00, $18/hr floor), the minutes-based pricing model, and the two fields excluded relative to ask_people. The example covers ask/kind/content/people/pay/minutes/pool, but pace, deadline_minutes, enough, ext, script, require, answer_fields, content_rating, wants_strangers and may_train_on_answers get no explanation anywhere.

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 first clause names a specific verb and resource and immediately frames the scope: 'Prices a call without opening it: nobody is rung and nothing is spent.' It then distinguishes itself from ask_people by field set ('Takes the same fields as ask_people, without max_total_usd or idempotency_key'), so an agent can pick this over its sibling without opening either schema.

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?

'Use it to get an amount your user can approve, or to see how people, pay or deadline move the price' gives the positive case, and 'Not needed when max_total_usd already covers what your user approved: ask_people opens nothing above it' gives the explicit exclusion plus the alternative. That is a complete when/when-not/alternative triad.

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