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

With no annotations present, the description carries the full burden for behavioral transparency. It indicates that the tool generates a report and lists valid query values, but it never states whether the operation is read-only, whether it has side effects, or how results are returned and paginated.

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 compact and well structured: a one-line purpose followed by short parameter, default, and value lists. There are no redundant sentences or filler.

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 combination of description and input schema provides enough to make a basic call: required parameters are formatted, defaults and valid values are listed, and an output schema exists. It falls short only on max_report_rows semantics and report-shaping details such as pagination or timezone.

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 description explains the format of account_name, start_date, and end_date, and enumerates valid and default values for dimensions and metrics, covering most parameters. max_report_rows is left without any explanation, and the meaning of individual dimension or metric values is not expanded.

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 opens with a specific verb and resource: 'Generate an AdMob mediation performance report,' and the parenthetical clarifies it covers earnings across ad sources. This is enough to distinguish it at a high level from sibling reporting 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 description includes concrete usage guidance: account_name format, inclusive date format, and defaults for dimensions and metrics. It does not explicitly state when to choose this tool over generate_network_report, so some situational guidance is missing.

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

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 does add useful context: defaults for dimensions and metrics, and the full list of valid values for both. It also specifies the account_name format and inclusive date range. However, it does not explicitly state that this is a read-only operation, does not mention any side effects, rate limits, or authentication needs, and does not describe the output format beyond what the output schema would provide. This is a moderate disclosure given the absence of annotations.

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 well-organized: a clear purpose sentence, followed by parameter format notes, then defaults and valid values. Every line contributes necessary information, and it is front-loaded with the main purpose. There is no redundant phrasing, and it uses line breaks to group related details, making it easy to scan.

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?

Given that an output schema exists, the description does not need to detail return values. It covers all required parameters' formats and the optional parameters' defaults and allowed values. It does not mention any prerequisites like the need for a valid account from list_accounts, but that is implicitly available through sibling tools. The only gap is the lack of explanation for max_report_rows, but overall it is sufficient for an agent to call 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 schema has 0% description coverage, so the description must compensate. It does explain the format for account_name ('accounts/pub-1234567890123456') and start_date/end_date ('YYYY-MM-DD', inclusive). It provides defaults and valid values for dimensions and metrics, which is beyond the schema. However, it does not explain the max_report_rows parameter at all, leaving it ambiguous. Overall, it adds significant meaning for most parameters but misses one.

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 it 'Generate an AdMob network (own ad serving) performance report.' The verb 'generate' plus the specific resource 'network performance report' is precise, and the parenthetical '(own ad serving)' distinguishes it from the sibling generate_mediation_report. An agent can immediately understand what this tool does.

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 explicitly scopes to 'network (own ad serving)', which implies it is for own ad serving reports as opposed to mediation. It provides the account_name format and date format, which are essential for usage. However, it does not explicitly name the alternative generate_mediation_report or state when not to use this tool, relying on the agent to infer the distinction from the scope.

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

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

With no annotations, the description carries the burden. It accurately describes a read-only 'Fetch' operation with no side effects, but it does not explicitly disclose permissions or confirm that no state changes occur. The description is not misleading, but it is minimal in its behavioral disclosure.

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 with no redundant words. It conveys the essential purpose and parameter format efficiently, making it highly scannable for an agent.

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?

Since an output schema exists, not describing the return structure is acceptable. The description covers what the tool does and the parameter format. It omits potential error cases or prerequisites, but for such a simple get operation, that information is not critical.

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?

Although the schema provides no description, the tool description compensates by giving a concrete format example ('accounts/pub-1234567890123456'). This clarifies the expected pattern for the account_name parameter, exceeding the schema's bare type definition.

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 specific verb 'Fetch' and the resource 'account's details', distinguishing it from list_accounts by indicating it retrieves a single account. The example format for account_name further clarifies the target.

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 does not explicitly state when to use this tool versus the sibling tools (e.g., list_accounts). It implies usage when a specific account_name is known, but this is not stated directly, leaving the agent to infer the appropriate context.

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

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

No annotations are provided, so the description carries the burden. It mentions 'accessible to this credential,' which implies read-only scoping, but does not explicitly state that the operation is non-mutating. Given the list nature, it is reasonable to assume read-only, but the absence of an explicit statement prevents a perfect score.

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, concise sentence with no extraneous information. It is well-structured and front-loaded with the action and resource.

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 is complete enough for a simple list operation with no parameters. It does not specify the output format, but that is often unnecessary for basic tools and may be covered by an output schema (not shown). Overall, it provides sufficient context for an agent to understand the tool's purpose.

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 schema has no parameters, so the description adds meaning by defining the resource type and the scope ('accessible to this credential'). This is sufficient for a parameterless tool.

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 action ('List') and the resource ('AdMob publisher accounts'), and it distinguishes itself from the sibling tool 'get_account' by implying a list-all operation rather than fetching a single account.

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 (to retrieve all accessible accounts) but does not explicitly state when to prefer this over get_account or other list tools. The context of sibling tools partially clarifies, but the description itself lacks direct guidance.

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

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

With no annotations, the description carries the full burden. It states a list operation (implying read-only) but does not explicitly mention that it is safe, nor does it disclose any side effects, permissions, or output details. The provided account_name format is helpful but pertains to parameter semantics rather than behavior.

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 that is front-loaded with the core action and includes the critical parameter format. There is no wasted wording, and it is appropriately concise for a simple tool.

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 tool is simple (one parameter) and has an output schema, so the description need not cover return values. However, it omits any mention of pagination, filtering, or read-only semantics. It is minimally adequate but could benefit from a note about the nature of the list (e.g., that it is read-only).

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 schema has zero description coverage for the single parameter, so the description must compensate. It provides the exact expected format of account_name ('accounts/pub-1234567890123456'), which is essential for correct invocation. This goes beyond the schema's bare type definition.

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 lists ad units under an account, with a specific verb and resource. It doesn't explicitly distinguish from sibling tools, but the resource (ad units) is distinct from accounts, apps, and reports, so it is understandable.

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?

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, such as needing an existing account, nor does it contrast with other list/generate tools. The usage context is left entirely to inference.

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

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

No annotations are provided, so the description carries the full burden. It states the operation is a list (read-only) and gives the account_name format, which is useful. However, it does not disclose pagination, ordering, or any other behavioral details. For a simple read operation, this is acceptable but minimal.

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 two short sentences with no filler. The key scope ('under an account') is front-loaded, and the parameter format is provided succinctly. Every word earns its place.

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 tool has an output schema, so return values are covered. The description is sufficient for a simple list operation with one parameter, given the sibling context. It could mention pagination or sorting, but those are minor for this use case.

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 coverage is 0%, so the description must compensate. It does so by specifying the expected format of account_name ('accounts/pub-1234567890123456'), which adds meaningful guidance beyond the bare string type in the schema. This fully clarifies the single parameter.

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 lists apps under an account, with a specific resource and scope. It is distinct from siblings like list_accounts (accounts) and get_account (single account), so an agent can easily tell 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?

There is no explicit guidance on when to use this tool versus alternatives. The description implies it is for listing apps, but does not mention when not to use it or how it differs from list_accounts or list_ad_units. The agent must infer usage from the name and context.

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