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

Annotations already declare this as a safe, idempotent, open-world read, so the bar is lower; the description still adds real behavioural context beyond them: the chart_provenance token's 15-minute validity window, its cross-replica portability, the fallback labelling as unverified_model_data when no receipt exists, and the mandatory attribution footer. It does not cover pagination, rate limits, or error behaviour of the connector itself, so it falls short of a 5.

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 front-loaded data-domain sentence is efficient, but the remainder is dominated by a long provenance/attribution policy block aimed primarily at chart_render, plus a restated data-accuracy contract. Much of this is genuine policy, yet it is verbose, somewhat repetitive ('verified provenance' / 'unverified_model_data' restated), and pushes the tool's own behaviour into the background.

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 and nested action-specific params, the description compensates well by defining the downstream contract (provenance token lifetime, source_path mapping, attribution footer handling) and the data-accuracy rules for derived metrics. What is missing is any statement about result volume, pagination, or partial-failure behaviour for the eight actions.

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 description coverage is 100%: every action and its action-specific params are documented inline in the schema, so the description is not obliged to explain them. It adds no syntax, format, or enum-value guidance of its own, which is the expected baseline of 3 when the schema does the heavy lifting.

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 sentence names the specific resource domain ('eBay seller data') and enumerates the eight data families (orders, transactions, seller standards, customer service metrics, traffic reports, funds summary) that map one-to-one onto the action enum. It is clearly distinguishable from the eBay name alone, though it never explicitly contrasts itself with near-neighbours like amazon_seller_connector or the gunbroker listing tools.

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 only when-to-use guidance ('When the user asks for a visual, trend, comparison, or recap, call chart_render...') routes the agent to a *different* tool rather than explaining when to select ebay_connector over sibling connectors. No exclusions, prerequisites, or connection-state requirements are stated; the correct action must be inferred from the enum.

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