Get Ad Account Activity Log

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not repeat that. The description adds the date format for since/until, but does not disclose any other behavioral traits such as rate limits, pagination, or what the returned log entries contain. Given the annotations cover the safety profile, this is a minor gap.

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 sentence followed by a clean parameter list. It is concise and front-loaded with the purpose. No fluff or redundant detail. The structure is clear and easy to parse.

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?

For a read-only log retrieval tool, the description is close to adequate but has notable gaps. It fails to document the response_format parameter even though it appears in the schema, and it does not describe what fields the activity log will contain or any pagination behavior. There is no output schema, so the description should at least hint at the return structure. The date range and limit are covered, but the omission of response_format is a clear deficiency.

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 only 20% (only response_format has a description), so the description should compensate. It does add context for since/until by specifying the YYYY-MM-DD format, which the schema lacks. However, it omits the response_format parameter entirely, which is a significant omission since that parameter has an enum and controls output format. The description adds value for some parameters but does not fully compensate for the low schema coverage.

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 states a specific verb ('Gets') and resource ('activity/change log for an ad account'), making it immediately clear what the tool does. It distinguishes itself from the many other 'get' tools in the sibling list by focusing on the activity log specifically.

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 usage (you call it when you want an activity log) but does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or alternative tools. There is no explicit guidance for choosing between this and other meta_get_ad_* tools, though the name and first line make the use case fairly apparent.

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