Merchant Center feed health

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

Beyond the annotations (read-only, non-destructive), the description discloses additional behavioral traits: data lags reality by ~30 minutes, and CRITICAL account-level issues can stop offers from serving entirely. This gives agents a clearer expectation of freshness and impact, going beyond the basic annotation hints.

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 description is dense but well-organized: a headline summary, an explanatory paragraph on why this matters (with concrete impact), and a clear parameter note. No fluff or redundant phrasing; every sentence contributes value.

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?

The description covers what the tool returns (counts, issues, docs, account problems), the source of the required parameter, and a known data freshness caveat. It does not explicitly outline the output schema, but that is provided separately. It also lacks explicit 'when to use vs. alternatives' guidance, which would make it fully complete. Overall, it gives sufficient context for an agent to invoke the tool correctly.

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?

The only parameter, account_id, is fully explained: it is a numeric Merchant Center ID and explicitly sourced from list_merchant_accounts. This is precise, actionable, and leaves no ambiguity about what the agent should pass.

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 description clearly states the tool's purpose: surfacing disapproved products and account-level issues in Merchant Center feed health. It lists the specific outputs (approved/pending/disapproved counts per context, top product issues with docs, account issues). However, it does not explicitly name any sibling tool to distinguish itself, relying instead on its unique domain (Merchant Center feed) to set it apart.

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?

The description provides situational context—disapproved feed items silently starve Shopping and Performance Max campaigns—which implicitly suggests when this tool is valuable. It also mentions a data lag (~30 minutes) that could affect timing. But it does not explicitly state 'use this when X' or compare with alternatives like health_check or run_realtime_report, leaving usage guidance somewhat implicit.

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