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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description usefully clarifies that results come from local configuration rather than a live remote API, consistent with openWorldHint=false, but it says nothing about what is returned, caching, or how authorization state is determined.

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?

A single, front-loaded sentence with no filler or redundancy. It is efficient, though its brevity is partly a symptom of under-specification rather than disciplined concision.

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 no parameters, the description carries the full burden of explaining what the agent gets back, yet it never describes the return shape (a list of resources? scopes? connection names?). It is adequate as a label but thin for a tool whose only value is its output.

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 tool takes zero parameters (empty properties, additionalProperties=false), so per the rubric the baseline is 4. There is nothing for the description to disambiguate on the input side.

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 verb 'Mostra' (shows) and the scope 'recursos explicitamente autorizados na configuração local' give a rough sense of purpose, and 'local configuration' does distinguish it from the remote-API siblings (gtm_read, ga4_admin_read, ga4_report, google_ads_search). However, 'recursos' is left undefined — an agent cannot tell whether these are scopes, APIs, accounts, or datasets, so the purpose remains vague.

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 contains no when-to-use guidance, no prerequisites, and no reference to any alternative tool. It never says to call this before the read tools to verify authorization, which is the obvious usage context given the sibling set.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered structurally. The word 'autorizada' hints that an authorized property is required, adding a small amount of context, but pagination behavior (pageToken) and per-resource behavior are undisclosed.

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?

A single short, front-loaded sentence with no waste, but its brevity comes from under-specification rather than discipline. Nothing extraneous, yet nothing beyond the minimum is present.

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 3-parameter tool with 0% schema coverage and no output schema, the description is far too thin. It does not describe what is returned per resource type or how results are paged, leaving significant gaps for the agent.

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 0% and the description adds no parameter meaning at all. It never explains the 'resource' enum values, nor that 'pageToken' exists for paging through large collections, leaving the agent to infer everything from the bare schema.

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?

States a specific verb ('Lê') and resource ('configurações de propriedade GA4'), which separates it from the reporting sibling ga4_report. However, it never mentions the resource kinds actually selectable (dataStreams, keyEvents, customDimensions, customMetrics), so the scope of 'configurações' stays vague.

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 when-to-use guidance and no explicit distinction from siblings such as ga4_report or gtm_read. Nothing tells the agent whether this is for admin metadata versus analytics data, nor when to prefer it over the alternatives.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context beyond that — a hard 1000-row output cap and that offset drives pagination — but says nothing about authorization requirements or rate limits implied by 'autorizado'.

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?

A single sentence with no padding, and the row cap and pagination constraint are stated up front. It is efficient, though extremely terse given the tool's 7 parameters.

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 7-parameter, 4-required tool with no output schema and zero schema description coverage, the description leaves too much unsaid: date formats, metric/dimension naming rules, propertyId format, and response shape are all missing. The line cap and pagination note are not enough to call it 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?

Schema description coverage is 0% across 7 parameters, so the description carries the full burden and largely fails it. It clarifies limit and offset semantics only, leaving all four required parameters (propertyId, startDate, endDate, metrics) with no format or meaning guidance in either place.

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 and resource ('Consulta relatório GA4'), and adds scope constraints (up to 1000 rows, offset pagination). It does not, however, distinguish this tool from sibling reads such as ga4_admin_read or gtm_read, so the agent must infer the boundary.

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 when-to-use guidance, no exclusions, and no mention of the alternative sibling tools. The agent gets an implied 'this retrieves reports' context but nothing that tells it when to pick this over ga4_admin_read.

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?

Annotations already declare readOnly, openWorld, and non-destructive, so the safety profile is covered. The description adds that the account must be authorized and that pageToken enables pagination, which is useful context, but says nothing about rate limits, result caps, or error behavior on invalid GAQL.

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?

A single compact sentence with no filler, front-loading the core action. It is terse to the point of leaving gaps, but nothing is wasted.

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, 0% schema description coverage, and three parameters, the description is too thin: customerId is unexplained, the return shape is unknown, and pagination behavior beyond 'accepts pageToken' is not described.

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 0%, so the description must compensate. It signals that 'query' must be a GAQL SELECT statement and that 'pageToken' is for paging, but customerId and its 10-digit format are left entirely to the schema pattern.

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?

States a specific verb (executa) and resource (consulta SELECT GAQL) scoped to an authorized account. GAQL is unique to Google Ads, which implicitly separates it from the ga4/gtm siblings, though no sibling is named explicitly.

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 guidance on when to choose this tool over ga4_report or gtm_read, nor any prerequisite beyond 'conta autorizada'. The read-only nature implied by SELECT is the only usage signal.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds a real behavioral detail — 'autorizados' indicates only resources the caller is authorized to see are returned — but says nothing about pagination despite exposing a pageToken.

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?

A single efficient sentence with the verb front-loaded. Nothing is padded, though the noun-list style trades brevity for precision about scope.

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 0% parameter documentation, the description should explain the required 'path' format and how pagination works — it does neither. An agent can guess the tool's domain but not how to construct a valid call.

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 0% on both parameters, so the description carries the full burden and fails it: 'path' (the GTM container/entity path, required, ≤250 chars) and 'pageToken' receive no explanation of format or purpose. The resource list hints at what path may select, but pagination semantics are completely undocumented.

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?

States a specific verb ('Lê') plus an enumerated set of GTM resources (container, workspaces, tags, triggers, variables, folders, versions), so the domain and operation are unambiguous. It stops short of distinguishing itself from siblings (ga4_admin_read, google_ads_search), though those clearly target different products.

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?

Usage is only implied: the resource list suggests reading GTM configuration entities, but there is no statement of when to choose this over the read siblings or any preconditions. No exclusions or alternatives are named.

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