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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly states the operation is a read ('Read aggregate...') and adds an important privacy guarantee ('without exposing buyer identities'). This is meaningful behavioral context beyond the tool name, though it does not cover caching, auth, or output shape.

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 a single, well-structured sentence that front-loads the core action and resource, then adds the privacy constraint. Every part earns its place, and there is no redundant restatement of the title.

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 the tool's main purpose and privacy stance, which is enough for a basic no-argument invocation. However, it does not document the optional 'days' parameter or describe what the response will look like, and there is no output schema to compensate. For a low-complexity tool this is adequate but not fully 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?

The input schema has a single optional 'days' parameter, but schema description coverage is 0% and the tool description never mentions it. The parameter's name implies a time window, but the description adds no explanation of how 'days' affects the returned metrics or whether it is a lookback period, which leaves meaningful ambiguity for an agent.

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 uses a specific verb ('Read') and names a concrete resource: aggregate discovery, quote, payment, confirmed revenue, and repeat-buyer metrics. It also adds a key scope qualifier ('without exposing buyer identities'), which helps distinguish this analytics-oriented tool from sibling tools like gf.quote or gf.payment_status that likely operate at a more transactional or identity-specific level.

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 implies this tool is for aggregate revenue metrics rather than buyer-level or individual transaction lookup, but it never explicitly states when to prefer it over sibling tools such as gf.free_profit_check, gf.payment_status, or gf.gcc_opportunity_score. There is no direct when-to-use or when-not-to-use guidance, only an implied analytics context.

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