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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description goes further by disclosing semantics the annotations cannot: absent vs empty/null meaning for offer fields, the distinction between stored offer fields and program_facts ('what outreach actually uses'), and the interpretation of a null rate. That is genuine added behavioral 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 first sentence is a good front-load, but the remainder is a dense run-on catalogue of returned fields with nested parentheticals, and the trailing 'Also notifications and re-scan cadence...' clause reads as an afterthought. The field semantics do earn some of their length, but the structure is list-like rather than prioritized.

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?

With no output schema, the description carries the full burden of describing return values, and it does enumerate most of the settings groups plus their edge-case semantics. A few entries stay vague ('product summary, market, marketing domain, Play link and the autopilot fit floor'), so it is strong but not exhaustive.

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?

Only one parameter (app_id) with 100% schema description coverage, including 'from list_apps' and the omit-to-use-most-recent default. The description adds nothing about app_id, but the schema already carries the full burden, so the baseline 3 is appropriate.

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?

It states the resource clearly ('everything App settings shows for a project') and enumerates the setting groups returned (offer, program_facts, follow_up_schedule, sending), so an agent knows this is the read-side counterpart of update_offer/set_autopilot. However it never names the verb explicitly (retrieve/read) and does not differentiate itself from siblings like get_program, get_autopilot, get_overview or get_deliverability, some of which likely overlap.

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?

There is no when-to-use guidance, no prerequisites, and no routing to alternatives. Given siblings such as get_account, get_overview, get_program and get_autopilot that plausibly expose overlapping settings, the agent is left to guess which read tool to call. The description only implies usage through its enumeration of contents.

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