Firenook

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

With no annotations, the description carries the full burden, and it does disclose the important non-obvious trait that this targets an emulator with synthetic data only. It does not state what happens on duplicate uid/email, whether the created account is returned (e.g. uid), or that all fields are optional, leaving meaningful behavioral gaps for a write operation.

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, front-loaded with the action and scope, with the safety constraint placed at the end. Every clause earns its place and there is no 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?

For an 8-parameter creation tool with no annotations and no output schema, the description covers purpose and safety but omits the return value, the fact that nothing is required, and how conflicts are handled. Adequate but with clear gaps for a mutation tool.

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%, so the baseline is 3. The description confirms which identity facets can be supplied (email/password, phone number, display name) and adds the synthetic-data constraint, but adds no format, validation, or interaction semantics beyond the 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?

The description names a specific verb and resource ('Create an Auth emulator account') and scopes it to a synthetic/emulator context, which clearly separates it from read/delete siblings like auth_get_user or auth_delete_user. What keeps it from a 5 is that no sibling is named explicitly and the set of optional identity fields is listed loosely (

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 one real usage constraint embedded — '(never real credentials)' — which tells the agent this is for test/emulator fixtures only. But there is no explicit statement of when to use this versus auth_mint_token, auth_set_claims, or how to proceed if a user already exists, so usage must be inferred from the tool name.

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 supplied, so the description carries the full burden. Beyond the word "Delete", it discloses nothing about irreversibility, whether the operation is idempotent or errors on an unknown uid, or what identity/permission context the emulator requires (the 'accounts:delete' API hint is not explained).

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 sentence, front-loaded with the verb and scoped with "one" and "by uid". Nothing is wasted, though the parenthetical endpoint is only marginally useful to 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?

The tool is structurally simple (one required string, no output schema), so the description is nearly sufficient. The remaining gap is consequential for a destructive, un-annotated operation: no warning about permanence or the safer sibling alternatives.

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%, so the uid parameter is already documented. The description restates that deletion is keyed on uid but adds no format, prefix, or lookup guidance beyond the 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 and resource: "Delete one Auth emulator account by uid", with the underlying emulator endpoint (accounts:delete). It is clearly distinguishable from siblings like auth_list_users or auth_get_user, though it never contrasts itself with the near-neighbor auth_disable_user.

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 versus auth_disable_user or auth_revoke_tokens, which are the obvious alternatives for the same resource. The agent is left to infer that deletion is the permanent option and that disable/revoke are non-destructive substitutes.

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, and it does disclose the two key behaviors: sign-ins and token refreshes fail, and the change is reversible. It does not say whether already-issued tokens are invalidated immediately, whether disabling an already-disabled account errors, or whether a multi-uid call is atomic — gaps that matter for an unannotated mutation tool.

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 that front-loads the action and immediately follows with the observable consequence. There is no redundant restatement of the tool name and no 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?

For a three-parameter, zero-required mutation tool with no annotations and no output schema, the description covers the effect and reversibility but leaves the calling contract underspecified. Nothing tells the agent what must be supplied (a call with no parameters is schema-valid) or what the response contains.

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%, so the baseline is 3. The description adds no meaning beyond the schema — it does not explain the uid vs. uids alternative, nor what omitting tenant implies beyond the schema's own note about project-level users.

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 ('Disable') on a specific resource ('an Auth emulator account') and states the concrete effect, so it is clearly distinct from auth_delete_user or auth_revoke_tokens. It stops short of naming auth_enable_user explicitly as the counterpart, so it does not fully reach the sibling-differentiation bar for a 5.

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 agent can infer this is the tool for making an account unable to authenticate, and the phrase 'until it is enabled again' hints at auth_enable_user as the reversing action. There is no explicit when-to-use versus auth_revoke_tokens/auth_delete_user, and no statement about preconditions such as the account existing or already being disabled.

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 exist, so the description carries the full burden. It does disclose that this operates on the Auth emulator, but says nothing about idempotency, what happens if the account is already enabled or missing, whether the change is reversible, or what the response contains — significant gaps for a mutation tool.

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 sentence with zero wasted wording, and the action is front-loaded. It is efficient but borders on under-specification rather than being an exemplar of tight, informative structure.

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 mutation tool with three parameters, no required fields, no annotations, and no output schema, this is too thin. An agent cannot tell whether uid or uids is expected, what error surfaces on an unknown account, or how this pairs with auth_disable_user.

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 100%, so uid, uids, and tenant are each documented in the schema. The description adds no meaning beyond that and does not address the ambiguity of both uid and uids being optional with no required parameter, so the baseline 3 applies.

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?

Names a specific verb ('Enable') and resource ('Auth emulator account') with a clear precondition ('disabled'). It is distinguishable from auth_disable_user by inversion, but it never names that sibling or the emulator-scope siblings, so differentiation is implicit rather than stated.

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 phrase 'Enable a disabled ... account again' implies the triggering condition (the account must currently be disabled), but there is no explicit when-not guidance, no mention of how to locate a disabled account (e.g., auth_list_users), and no pointer to auth_disable_user as the inverse operation.

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 supplied, so the description carries the full disclosure burden, and it adds almost nothing behavioral: it does not say the call is read-only, what happens when no account matches, or whether an error vs. empty result is returned. It also leaves unstated whether one, two, or all three of uid/email/phoneNumber may be supplied at once, which is the main ambiguity for a zero-required-parameter lookup.

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 naming the verb, resource, cardinality, and selector set, with no filler. The trailing API operation name is useful for agents matching on backend endpoints.

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 tool with no annotations, no output schema, and zero required parameters, the description should at minimum state that at least one identifier is needed, whether identifiers combine or take precedence, and what is returned (a profile vs. a not-found result). None of that is covered, leaving an agent likely to call it with an empty argument object.

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%, so the schema already documents each of the three parameters clearly, making 3 the baseline. The description enumerates the same three selectors but adds no precedence rule for the case where multiple identifiers are provided, so it contributes little meaning beyond the 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 ('Look up') and resource ('one Auth account') plus the three accepted selectors, and the parenthetical '(accounts:lookup)' names the underlying Identity Toolkit operation. It implicitly contrasts with the listing sibling, but never names auth_list_users, so differentiation is left to inference.

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?

'Look up one Auth account' implies single-account retrieval as opposed to the bulk listing done by auth_list_users, but no explicit when-to-use/when-not guidance is given. An agent must guess between this and the many other auth_* siblings (mint_token, set_claims, etc.) from names alone.

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; "List" implies a non-destructive read, and it usefully discloses that user counts and sign-in settings come back. It does not state what happens when no tenants exist, whether the emulator must be started, or how truncation by limit is signaled, leaving real gaps for an unannotated tool.

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?

One sentence, front-loaded with the verb and resource, with the returned fields appended rather than buried. No filler or redundancy.

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 simple two-optional-parameter read tool with full schema coverage and no output schema, the description covers purpose and the shape of the result. Minor omissions remain around emulator preconditions and pagination semantics, but nothing essential to invoking it correctly is missing.

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% and both parameters are documented in the schema (substring matching on id/display name, maximum 500 with default 500). The description adds no syntax or behavioral detail about q or limit, so baseline 3 applies.

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 and resource ("List the Auth emulator's tenants") plus the fields returned (user counts, sign-in settings), which clearly separates it from the user-oriented siblings like auth_list_users and auth_get_user. It stops short of naming an alternative explicitly, but the resource distinction is unambiguous.

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 on when to use this versus auth_list_users, nor any prerequisite such as the Auth emulator needing to be running. The agent must infer the emulator context and the multi-tenancy scope from the parenthetical alone.

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 supplied, so the description carries the burden. It usefully discloses the shape of each returned account (uid, email, phone, display name, claims, provider data), which substitutes for the absent output schema, but says nothing about ordering, result caps, whether disabled users are included, or pagination semantics beyond what the schema already states.

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 the resource, the backend call, and the return payload — no filler, nothing an agent must scan past to find the core purpose.

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 two-parameter, read-only listing tool with no output schema, the description covers the essentials: what is listed, the backend method, and the fields returned. Minor gaps remain around ordering and whether pagination terminates with a token, but nothing critical to correct invocation is missing.

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% — pageToken is documented as "Continue a previous listing" and maxResults as "Page size; default 100". The description adds no additional meaning about either parameter, so the baseline 3 applies.

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 and resource ("List Auth emulator accounts") and even names the underlying API (accounts:batchGet), plus the fields returned. It is clear this enumerates accounts rather than acting on one, though it never explicitly contrasts itself with auth_get_user for single-record lookups.

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 implied by the verb "List" — an agent can infer this is the enumeration path versus the single-user siblings like auth_get_user or the mutating auth_set_claims/auth_disable_user. However there are no explicit when-to-use or when-not-to-use statements, and no guidance on when to page versus fetch everything.

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 disclosure burden and does reasonably well: token lifetime is one hour, claims are scoped to this token and nothing is persisted, and the user must already exist. It omits prerequisites (Auth emulator must be running), permission/credential requirements, and any failure modes for unknown uids.

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 the action, validity window, subject constraint, and intended follow-on use front-loaded, followed by the one non-obvious caveat about claims. No filler or redundancy.

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 4-parameter mutation tool with no annotations and no output schema, the description is largely sufficient: it explains what is issued and its lifetime. Minor gaps remain around environment prerequisites and behavior on an invalid uid/tenant.

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 100%, so uid, claims, tenant, and provider are already documented in the schema. The description reinforces the claims semantics (temporary, per-token override) but adds no new format, default, or interaction detail beyond the schema; baseline 3 applies.

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 and resource (mint a Firebase ID token + refresh token) plus the scope (existing Auth emulator user) and the outcome (act as that user in function/REST calls). The 'claims replace custom claims for this token only' clause also separates it from the persistent-claims siblings like auth_set_claims.

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?

Gives a clear use context: when an agent needs to call a function or the REST API as a specific user. It does not name alternatives explicitly (e.g., use auth_set_claims to persist claims instead, or auth_revoke_tokens to invalidate), so it stops short of full when/when-not routing.

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 supplied, so the description must carry the behavioral burden. It usefully discloses that the emulator stores codes rather than emailing them, but it does not say whether reading consumes or clears codes, whether access is read-only, or what permissions are needed.

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 a clarifying parenthetical; every element earns its place and there is no redundant text.

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 zero-parameter tool, the description covers what the resource is and its emulator context, but with no output schema it does not describe the shape of returned codes or whether calling has side effects.

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?

There are zero parameters, so the schema imposes no parameter-learning burden. Per the baseline for parameterless tools, 4 is appropriate; the description adds no parameter details because none exist.

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?

Identifies the exact resource and enumerates the kinds of codes (email verification, password reset, sign-in links), but uses a noun phrase with no retrieval verb and does not distinguish it from the sibling auth_verification_codes.

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 'instead of sending email' context implies use during emulator-based auth testing, but there is no explicit when-to-use statement, no exclusions, and no named alternative such as auth_verification_codes.

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 at all, the description carries the full burden, and it does disclose the key merge behavior ('keeping its other claims'), which is genuinely useful for a mutation tool. It omits other behavioral facts an agent needs: whether removal is idempotent, what happens if a named key does not exist, whether the change persists in the emulator, and any auth/permission requirement.

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 the action, target, and the non-obvious preservation guarantee. No filler, no restating of the title, nothing that could be cut.

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 simple four-parameter mutation with no annotations and no output schema, the description covers the core contract but leaves the bulk (uids) path, tenant behavior, and error semantics to the schema. It is adequate as a minimum-viable definition but not complete for an agent operating without annotations.

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%, so all four parameters (uid, keys, uids, tenant) are already documented, making 3 the baseline. The description adds only 'custom claim keys' framing and implicitly confirms partial-merge semantics; it says nothing about the uid vs uids bulk alternative or tenant scoping beyond what the schema states.

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 names a specific verb ('Remove') and a specific resource ('named custom claim keys from an Auth emulator user'), and explicitly states the scoping behavior that other claims are preserved. It is clearly distinct from auth_set_claims by virtue of 'remove', though it never names that sibling 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?

Usage is only implied: an agent can infer this is the deletion counterpart to auth_set_claims, but the description never says when to prefer this over setting claims to null, nor does it mention the bulk path (uids) or the tenant-scoping case. No when-not guidance is given.

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 and does disclose a meaningful mechanism (validSince moves to now), which is real value beyond structured data. It omits key behaviors for a session-invalidating operation: whether uid or uids is required in practice (both are optional in the schema), what happens when neither is supplied, whether the call is reversible, and whether it affects only emulator state.

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 the verb first and the behavioral consequence in a parenthetical; nothing is wasted or buried.

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 three-parameter mutation with no annotations and no output schema, the description covers purpose and effect but leaves gaps an agent needs: behavior with zero arguments, return value (count revoked? nothing?), and scope restrictions beyond 'Auth emulator'.

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%, so the schema already explains uid, uids, and tenant, including that uids is used 'instead of uid.' The description adds no parameter-level meaning (no mutual exclusivity rule, no note on omitting uid to target all users), so the baseline 3 applies.

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 and resource ("Revoke ... refresh tokens") scoped to an Auth emulator user, and the 'sessions must sign in again' clause separates it from siblings like auth_disable_user or auth_set_claims. It stops short of explicitly naming an alternative, but the action is unmistakable.

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: an agent can infer 'call this when you want existing sessions invalidated,' but there is no explicit when-to-use, when-not-to-use, or guidance on choosing it over auth_disable_user / auth_delete_user for locking a user out.

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 and does disclose the key mutation semantics: replace overwrites the entire claim set, merge touches only the supplied keys, and a null value deletes a key. It omits side effects an Auth caller would care about, such as whether existing ID tokens must be refreshed and how errors are surfaced.

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 that leads with the operation and then the mode semantics; every clause carries information, with no filler or repetition of schema fields.

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?

Covers the core claim-setting semantics for a mutation tool, but with five parameters including a multi-user 'uids' array and no output schema, it says nothing about per-user behavior or what a call returns. Adequate for calling the tool, incomplete for predicting the outcome of a multi-uid 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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: what 'replace' and 'merge' actually do and the null-value removal convention inside the claims object. It adds nothing about uid vs uids vs tenant selection, which the schema already handles.

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 and resource ('Set an Auth emulator user's custom claims') and immediately disambiguates the two operating modes, replace vs merge, plus the null-removes-key rule. An agent can distinguish this from siblings like auth_remove_claims or auth_mint_token without opening the schema.

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?

Gives clear selection guidance between the two modes and explains that replace mirrors the Admin SDK's setCustomUserClaims, which tells the caller when replace is the right choice. It does not name alternatives or state prerequisites such as the user having to exist or the emulator being active.

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 does disclose a genuinely useful behavioral fact — the emulator intercepts these codes instead of sending SMS — which helps an agent understand why this data exists and that it is emulator-only. However, it never states that the operation is read-only, whether reading consumes or leaves the codes pending, or what the returned codes look like.

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 sixteen-word sentence with no filler, and the key qualifier ('pending') is front-loaded. The fragmentary, verb-less construction is the only structural weakness — a leading verb such as 'List' would make the call direction unmistakable at no length cost.

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 (no parameters, no nesting), but with no annotations and no output schema the description is the only source of truth about the result set, and it never says what each entry contains (phone number, code, expiry, timestamp) or whether multiple codes can be pending at once. It explains the concept well but leaves the agent guessing about the return shape.

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, so there is no parameter meaning for the description to add and the baseline of 4 applies. The description correctly implies the call is unfiltered — it returns the pending codes rather than the pending codes for a given user or phone number.

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 names a specific resource — pending phone verification codes — and adds the distinguishing detail that these are held by the Auth emulator rather than sent as SMS. It is a noun phrase with no verb, so an agent must infer that this is a read/list operation, and it does not explicitly contrast itself with the nearby auth_oob_codes sibling. Still, the resource is identifiable without opening the schema.

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 at all: nothing says when to call this rather than auth_oob_codes, auth_mint_token, or auth_verification-style siblings. The one implicit cue is the word 'pending', which suggests inspecting in-flight codes during emulator testing, but the agent must supply that reasoning itself.

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 and does well: it front-loads 'DESTRUCTIVE' and spells out the blast radius down to Auth tenants, Pub/Sub schemas and messages, and Cloud Tasks history. It omits whether the operation requires elevated auth/permissions, whether it is reversible, and what the response contains.

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?

Two sentences: a front-loaded DESTRUCTIVE warning followed by the multi-service safeguard. The parenthetical enumeration is dense but every clause names a distinct destructive surface, so 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?

For a high-risk bulk-mutation tool with no annotations and no output schema, the definition covers the crucial parts: what is destroyed and the confirmation requirement. It could still note whether this targets only the local emulator environment and what the tool returns after clearing.

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%, so the schema already documents all three parameters. The description reinforces the confirmProject safeguard but adds no meaning beyond the schema for sections or runTriggers (the 'Firestore only' note is already in the 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?

Specific verb (delete) plus an exhaustive enumeration of the resources affected across all five services, so an agent knows exactly what the tool wipes. It is clearly distinguishable from narrower siblings like firestore_delete, storage_delete, or auth_delete_user, which operate on individual records.

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 states the confirmProject prerequisite for multi-service clears, which is real usage guidance, but it never says when to pick this tool over the granular delete siblings (e.g., clearing only some documents). No exclusions or 'do not use when' guidance is offered.

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 behavioral burden. It states that the data is 'running' and exported outside the project, but does not disclose the filesystem write effect, overwrite behavior when the destination is non-empty, prerequisites such as the emulator being active, or failure conditions.

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 front-loaded sentence with no wasted wording. The parenthetical command alias is compact and does not obscure the core action.

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 two-parameter export tool with full schema coverage and no output schema, the description is adequate to identify the operation and destination. However, with no annotations, it should say more about the write/overwrite behavior and any prerequisites to be complete for safe invocation.

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 description coverage is 100%, so both parameters are already documented. The description adds the useful context that the destination is outside the project, but it does not add meaning beyond the schema for the 'force' parameter or the overwrite/foreign-directory semantics.

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 ('Export') and names the resources ('Firestore, Auth and Storage data') plus the destination scope ('a directory outside the project'). It clearly distinguishes the operation from read/query siblings, but it does not explicitly contrast with the closest sibling, emulators_clear.

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 by saying it exports running emulator data to an external directory, which suggests backup or migration scenarios. It gives no explicit when-to-use/when-not-to-use guidance and never mentions emulators_clear or other 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?

Since no annotations are provided, the description performs the crucial task of disclosing behavioral traits by listing specific returned metadata, such as outcome, duration, and invocation id for function delivery.

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 definition is concise, delivering maximum functional information in a single, dense sentence without unnecessary jargon.

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?

By detailing exactly what data is returned (attributes, data, delivery info), it provides sufficient context for an agent even without a formalized output schema.

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 schema coverage is 100%, the description adds essential domain knowledge regarding the specific ID format and its source, preventing the agent from passing a CloudEvent ID incorrectly.

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 retrieves a specific Eventarc event, including its attributes and associated function delivery data. It identifies the target resource and what it contains.

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 guides usage by clarifying that the ID must come from eventarc_list_events and uses the specific format (<nonce>-<seq>), which distinguishes it from a CloudEvent ID.

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 exist, so the description carries the full burden. It usefully discloses sort order and the composition of the result set plus the per-event match/delivery counts, which goes beyond a bare 'list'. However it omits behavior an agent needs: whether this is strictly read-only, what an empty suite returns, how pagination via cursor behaves, and whether counts reflect per-attempt deliveries.

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 dense sentence with the ordering constraint front-loaded and no redundant restatement of the name. It is efficient, though the parenthetical listing of event sources is slightly crowded for one clause.

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, the description does the necessary work of explaining what a returned event record contains (source categories plus matched/received/failed counts) and its ordering. The main residual gap is pagination/limit behavior and any permission scope, which for a zero-required-parameter read tool is minor.

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%, so all four parameters (q, limit, cursor, channel) are already documented in the schema, including example filter syntax and the default of every channel. The description adds no filtering or pagination semantics beyond that, so the baseline 3 applies.

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 names the resource (Eventarc events received by the suite), the ordering ('newest first'), the event provenance (custom, replays, Firebase services' own) and the payload's distinctive field (per-event function matched/received/failed counts). It is clearly a listing tool and distinguishable from eventarc_get_event and eventarc_replay_event, but it never names those siblings 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?

Usage is only implied: 'the events the suite received' suggests a browse/history use case, but there is no statement of when to prefer this over eventarc_get_event for a single event or eventarc_publish/replay, and no mention of prerequisites such as which channels are visible.

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 exist, so the description carries the full behavioral burden. It does disclose the default channel behavior and that the call reports recipient functions and per-call outcomes, but says nothing about side effects (this invokes real deployed functions), permission/auth requirements, whether delivery is synchronous, or what happens when no function subscribes.

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, and the reporting behavior is appended where it belongs. The 'as getEventarc().channel().publish() does' clause is compact but slightly opaque to an agent without the SDK context.

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?

Seven parameters are all documented in the schema, and although there is no output schema, the description covers what comes back (which functions received it, how each call ended). What is missing is failure/edge-case behavior — no subscribers, invalid type, channel not found.

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%, including the channel default and the data/text alternative, so the schema does the parameter work. The description adds no extra meaning about precedence between data and text or about attribute merging beyond what the property descriptions already state.

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 and resource — 'Publish a custom CloudEvent to an Eventarc channel' — plus the default channel target. It does not explicitly name pubsub_publish or eventarc_replay_event as the alternatives, so an agent must infer the distinction from the resource noun alone.

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 implied (emit an event so functions receive it, useful for testing delivery) but never stated as when-to-use or when-not-to-use. Given siblings pubsub_publish, functions_invoke, and eventarc_replay_event all send or re-trigger events, the absence of routing guidance is a real gap.

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 and does disclose the key behavioral trait: a *new* event is produced with origin 'replay', and the tool reports the resulting deliveries. It does not say whether matched functions actually execute as a side effect, whether replay is idempotent, or what permissions are required.

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 the action, target, and result stated up front; the parenthetical '(a new event, origin replay)' adds semantics rather than 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?

A side-effecting mutation with no annotations and no output schema needs the description to explain consequences and return shape. 'Report the new deliveries' hints at the response, but the effect on matched functions and any irreversibility are left unstated.

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 100% and the schema itself explains the subtle id distinction (Eventarc id vs CloudEvent id) and the keepId default. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline applies.

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 chain (re-deliver a received event to matching functions) plus the distinguishing qualifier that this is a replay of an existing event rather than a publish. An agent can separate it from eventarc_publish and eventarc_list_events, 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?

Usage is only implied: you call it when you want to re-deliver an event you previously received. There is no explicit when/when-not guidance and no pointer to eventarc_publish or functions_replay_call as alternatives, both of which could be confused with re-running a function against an event.

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 at all, the description bears the full burden of behavioral disclosure. It conveys the observable state values (running, loading, failed) and that load errors are included, which is useful, but it never states that this is a non-mutating read, what happens if the emulator is not running, or how ordering/pagination works.

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 dense sentence with no filler, and the most important content (what instances are returned and their state) is front-loaded. The phrasing is slightly awkward as an unpunctuated noun phrase, 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?

For a zero-parameter list tool with no output schema, the description does the heavy lifting by sketching the returned fields: reference, version, state, load error, function count. That is reasonably complete for the return shape, but the absence of any statement about read-only behavior or emulator preconditions leaves a gap.

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, so the baseline is 4 by rule; there is nothing for the description to clarify about inputs, and it correctly spends no words on parameter semantics.

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 names the resource ('Firebase Extensions instances the suite runs') and enumerates its fields, so an agent can infer this is a read/list operation. But there is no explicit verb — it is a noun phrase describing contents rather than stating 'list all extension instances', and it never distinguishes itself from siblings like extensions_reload.

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, no mention of prerequisites (e.g. that the emulator/suite must be running, which the phrase 'the suite runs' only hints at), and no routing to or from extensions_reload. The agent must guess that reload is the mutation counterpart.

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 disclosure burden. It does well to say that functions are restarted and that state and functions are reported afterwards, which signals a disruptive operation, but it omits whether in-flight invocations are dropped, whether the reload is atomic or can fail mid-way, and whether any permissions are required.

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 the verb first, a clarifying parenthetical that earns its place, and a note on what is returned. No filler or redundancy.

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 single-parameter mutation with no output schema, the description covers what triggers the operation, what it does internally, and roughly what comes back. The remaining gap is failure/partial-failure behavior and required permissions.

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?

Only one parameter, and the schema already documents it at 100% coverage with a concrete example ('resize-images'). The description adds the constraint that it operates on exactly one instance, but supplies no additional identifier format or lookup semantics beyond the 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 ('Reload') and a specific resource ('one Extensions instance'), and the parenthetical spells out concretely what reload means: re-reading .env parameters and source, restarting functions. It is clearly distinct from the sibling extensions_list (read-only listing) without naming it explicitly, which holds it short of a 5.

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 implied by the mechanics ('re-read its .env parameters and source'), suggesting it is the tool to call after changing configuration. However, there is no explicit when-to-use/when-not statement, no mention of prerequisites (e.g. the instance must already exist), and no routing to alternatives such as extensions_list for inspection.

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 does disclose the response contents, which is the main behavioral trait for a status call, and a zero-parameter tool has no mutation surface to warn about. However, it says nothing about what happens when nothing is running, whether the call fails or returns an empty listing, or about the cost/latency of probing locators.

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?

It is a single sentence with no filler, but it is a verbless noun-phrase list with an awkward trailing clause ('with no project, the suites whose locators answer') that takes a re-read to parse. Front-loading 'The running Firenook suite' is good; the list structure sacrifices clarity for brevity.

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?

There is no output schema, so the description must explain the return value, and it does attempt that by naming the fields. But several entries are opaque – 'how the project was found' and the fallback clause do not tell an agent what the actual shape or keys of the response will be, which is the main gap for a diagnostic tool.

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 zero parameters, so there is no parameter semantics to document and the baseline of 4 applies. The description correctly implies there are no inputs to vary, only a mode difference driven by whether a project is configured.

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 enumerates exactly what the tool reports: hub locator, hub status, per-service emulator host/port, and CLI version. That is specific enough to separate it from every sibling (all of which operate on a single resource such as firestore_get or emulators_clear). It stops short of a 5 because there is no verb – the reader must infer 'reports/returns' from the noun phrase 'The running Firenook suite'.

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 field list suggests calling it to discover the hub and emulator endpoints before invoking other tools, and the trailing clause hints at a fallback discovery mode when no project is set. There is no explicit when-to-use, no when-not-to-use, and no named alternative among the 50+ siblings.

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 does disclose that this is an aggregation that reads no documents, which implies a read-only, low-payload operation. It says nothing about required permissions, consistency/accuracy of the count, or billing/cost characteristics of aggregation queries, all relevant for a Firestore count tool.

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 that opens with the verb and resource, then layers scope qualifiers. It is dense with nested clauses and parentheticals but contains no 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?

For a four-parameter read tool with full schema coverage, the description covers the core semantics and the key behavioral note that no documents are returned. The absence of an output schema would normally require the description to say what comes back; 'count' implies a numeric total, which is adequate but leaves the exact response shape implicit.

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%, so all four parameters including the collectionGroup depth semantics are already documented in the schema. The description restates that where filters are optional and that collectionGroup targets collections by id at any depth, but adds no syntax or behavioral detail beyond the structured fields.

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 names a specific verb and resource (count documents of a collection) and qualifies the scope with collectionGroup and where filters. The parenthetical '(a COUNT aggregation; no documents are read back)' implicitly distinguishes it from firestore_query and firestore_get, though it never names those siblings outright.

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 'use this when...' guidance or reference to firestore_query as the alternative. The phrase 'no documents are read back' hints that this is the cheap path when only a tally is needed, but the agent must infer that choice itself.

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 at all, the description carries the full behavioral burden. It usefully discloses the destructive scope of recursive:true for both documents and collections, which is the most important behavioral trait here, but it never states that deletion is irreversible, what happens when the path does not exist, or what the call returns.

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?

One front-loaded sentence with a clear verb, and the nested parentheticals are dense but each carries information about the recursive flag. Nothing is padding, though the doubled parenthetical structure reads awkwardly.

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 a fully documented schema, no output schema, and no annotations, the description covers the key decision point (recursive scope). The main missing piece is any note on irreversibility or error behavior, which matters for a delete tool.

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%, so the baseline is 3. The description adds some meaning beyond the schema by explaining recursive in the context of both a document path and a collection path, but it says nothing extra about the database parameter or path formatting rules.

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 (delete) and two resource types (document, collection) and explains how the recursive flag changes the target set in each case. An agent can distinguish this from firestore_set or firestore_get without inspecting the schema, though it never names those siblings 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?

Usage is implied rather than stated: the recursive semantics hint at when each mode applies, but there is no explicit guidance on when to delete a collection path instead of individual documents, no prerequisites, and no mention of alternatives such as firestore_set with null data.

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 behavioral burden. It usefully discloses the return shape ('fields as plain JSON') and the not-found behavior ('exists:false' rather than an error), but says nothing about permissions/auth requirements, latency, or error modes for malformed paths.

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 that front-loads the verb and resource, then packs the path grammar and return contract into a parenthetical. No redundant or filler wording.

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 two-parameter read tool with no output schema, the description covers the path format and the shape of a successful versus missing-document result, which is what an agent needs to call it correctly. Auth expectations and failure behavior on invalid paths are the only notable omissions.

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 100%, so the baseline is 3. The description goes beyond the schema by spelling out the nested path grammar 'collection/document[/subcollection/document]', which the schema's flat example 'users/alice' does not convey. It does not address the optional 'database' parameter, but the schema documents that adequately.

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 ('Read one Firestore document by path') and scopes it to a single document, which implicitly distinguishes it from firestore_query (multi-document) and firestore_set/firestore_delete. It does not name those siblings explicitly, so the differentiation is inferred rather than stated.

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 singular 'one ... document' implies the single-fetch use case versus the sibling firestore_query, but there is no explicit when-to-use or when-not-to-use guidance, and no mention of prerequisites. An agent can infer the routing but must do so from wording alone.

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 supplied, so the description must carry the safety profile, and 'List' reasonably signals a non-mutating read. It does not address pagination behavior, permission requirements, or whether nested subcollections are returned, which are real concerns for a listCollectionIds-style call.

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 the operation stated first and the scope second. The parenthetical API method name is marginally useful for cross-referencing but is the only semi-redundant element.

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 two-optional-parameter read tool with no output schema and full schema coverage, the description supplies the essential scope and gestures at the return value (collection ids). Additional behavior detail would help but nothing critical is missing.

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 100%, so the parameter descriptions already explain path and database fully. The description reinforces the path semantics by stating the root-vs-document distinction, adding a little meaning on top of the schema, so it edges above the baseline 3.

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 and resource ('List collection ids') plus the two scopes it operates over, root or a document. That distinguishes it from firestore_get, firestore_query, and firestore_count, though it never names a sibling 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?

Usage is implied by the scoping clause -- omit path for root collections -- but the tool offers no explicit when-to-use/when-not guidance or alternatives such as firestore_query for reading document contents. An agent must infer this is the discovery/enumeration step.

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 supplied, so the description carries the behavioral burden; it does disclose read semantics, the collection-vs-collection-group scope difference, and that results come back as plain JSON. It omits operationally important traits: Firestore's composite index requirement, pagination/cursor behavior, result-size limits, and the fact that the 50-document default cap can silently truncate results (the default appears only in the schema).

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?

One dense sentence that front-loads the core action and appends scope and return-shape clauses; nothing is redundant. It is slightly overloaded with the parenthetical 'Firestore runQuery' reference and the collectionGroup parenthetical, but no sentence 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?

For a 6-parameter, fully documented schema with no output schema, the description covers the action, both query scopes, and the return format, which is close to sufficient. The main gaps are index requirements and result-limit/truncation behavior, which matter for real Firestore queries but are not strictly needed 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?

Schema description coverage is 100%, so the baseline is 3. The description reinforces that where/orderBy/limit are optional but adds no syntax or format detail beyond the schema, which already documents AND-combined filters, sort direction defaults, and collectionGroup path semantics in more depth than the description does.

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 ('Run a structured query over one collection') and explicitly covers the collectionGroup variant plus the return shape ('matching documents as plain JSON'). It implicitly separates itself from single-document siblings like firestore_get and counting sibling firestore_count by describing filtered/ordered multi-document retrieval, though it never names an alternative outright.

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 implied through the optional where/orderBy/limit clause: an agent can infer this is the tool for filtered or sorted reads. However, there is no explicit guidance on when to prefer firestore_get, firestore_count, or firestore_list_collections, and no note about prerequisites such as composite indexes for multi-field filters.

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 and does real work: it discloses that the default behavior replaces the entire document (a destructive, data-losing default) and that merge:true limits the write to top-level fields. That top-level-only nuance is a meaningful caveat an agent could not infer elsewhere. Missing are permission requirements, whether a document is created when absent, and the return 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?

A single sentence using a colon to front-load the action and then the two modes. No filler, no repetition of the tool name, and the most consequential fact (replace by default) appears first.

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 mutation tool with no annotations, no output schema, and a nested 'data' object, the description covers write semantics well but leaves gaps around return value, error behavior, and whether a missing document is created. Those omissions matter for a writer tool that an agent must call correctly on the first try.

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 100%, so the baseline is 3, but the description adds meaning beyond the schema: it clarifies that 'data' is plain JSON and that merge:true affects only top-level fields, which the terse schema description 'Merge into the existing document' does not convey. It says nothing about the 'database' parameter, however.

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 ('Write a Firestore document') and immediately contrasts the two write modes (full replace vs. merge:true). It doesn't name a sibling tool, but the replace/merge framing alone differentiates it from firestore_get, firestore_query, and firestore_delete.

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 default-vs-merge choice is well signposted, so an agent knows which mode to pick. There is no explicit when-not guidance, no mention of how this differs from creating a document that doesn't yet exist, and no alternative tool is named.

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, and it does disclose the full content payload including nested error and stack trace and timings, which is meaningful behavioral detail. However, it never states that this is a non-mutating read, whether call records expire or are retention-limited, or what happens when an id is unknown.

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 dense sentence that front-loads the resource and then lists contents in a scannable order; every item listed is real content of the response. It reads as a fragment without an explicit verb, which slightly weakens the opening.

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, the description must describe return values, and it does so thoroughly. But for a diagnostic fetch tool with no annotations and no error semantics, an agent is left guessing about read-only status, record retention, and not-found behavior.

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 100%, so both parameters (id and maxBodyChars) are fully documented in the schema, setting a baseline of 3. The description mentions 'body' and 'response' but adds nothing about truncation behavior or why maxBodyChars matters, so it does not exceed the 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?

The description names the resource ('One function call') and enumerates exactly what is returned: cause, request, response, event payload, error with stack trace, console output, timings. An agent can tell it fetches a single call record rather than a list, though it never explicitly contrasts with functions_list_calls or functions_replay_call.

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 or when-not guidance appears in the description; the only routing hint ('Call id from functions_list_calls') lives in the schema, not the description. An agent must infer that this is the drill-down after listing calls and the pre-step before replaying one.

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 at all, the description carries the full behavioral burden. It does add real context: the payload is shaped as the official functions shell sends it, and the event body varies by trigger type (Firestore before/after, Storage, Pub/Sub, Auth, schedule, Eventarc, task queue). It omits the operationally important parts — that this executes arbitrary user code with real side effects, whether the call blocks until the function returns, timeout/error behavior, and what a failed invocation looks like.

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 dense sentence, front-loaded with the verb and the two-mode split, with no filler. The long parenthetical event-source list is informative but makes the sentence heavy; a short second sentence enumerating the modes would read better.

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 9-parameter tool that executes code and has no output schema, the description is adequate but incomplete: it never says what comes back (the function's return value? a status? an error envelope?), which is the key unknown when no output schema exists. The unused-in-description parameters (`auth`, `params`, `method`, `region`, `resource`, `eventType`) are covered by the schema, so the gap is mainly around results and failure modes.

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%, so baseline would be 3. The description earns the bump by explaining the cross-parameter relationship the schema cannot: `data` pairs with the callable path (sent as {"data": ...}) while `eventData` selects the background path and determines the payload shape, with `eventType` as the Eventarc override. This maps parameters to modes rather than merely restating them.

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?

Names a specific verb ("Invoke") and resource ("a loaded function"), and immediately splits the operation into its two real modes: an HTTPS/callable request driven by `data`, or a background event driven by `eventData`. It stops short of distinguishing itself from nearby siblings such as `functions_replay_call`, `functions_list_calls`, or `eventarc_publish`, which an agent could plausibly confuse it with.

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 the usage condition — the function must already be loaded/emulated — and the data-vs-eventData split implicitly tells you which mode to pick. But there is no explicit when-to-use versus alternatives, no statement of prerequisites (does the emulator need to be running? does the function need to be deployed?), and no guidance on when to prefer `functions_replay_call` or `eventarc_publish` instead.

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 supplied, so the description bears full behavioral burden. It does disclose the observable content of each entry (name, region, generation, trigger kind, event type/schedule, HTTPS URL), which implies a read-only enumeration, but it says nothing about ordering, pagination, empty results, or whether the list reflects live runtime state at call time.

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 a colon-delimited field list; nothing is repeated or wasted. The most important information (what is listed) comes first and the field enumeration follows.

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 input parameters and no output schema, the description usefully compensates by enumerating the returned fields, which is exactly what the structured data omits. Minor gaps remain around volume of results and whether the list can be empty or stale.

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, so the baseline is 4. No parameter meaning is required, and the description correctly focuses its detail on the output rather than inventing input semantics.

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+resource ('The functions loaded by the running suite') and enumerates the fields returned. It is clear what the tool does, though it never names or distinguishes itself from nearby siblings such as functions_list_calls or functions_get_call, which an agent could plausibly confuse with a listing of functions.

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 qualifier 'loaded by the running suite' implicitly scopes usage to the currently running emulator/suite rather than deployed cloud functions, which is useful context. However, there is no explicit when-to-use, when-not-to-use, or pointer to an alternative tool for deployed functions or for call logs.

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 supplied, so the description carries the full behavioral burden. It does disclose useful traits beyond structure: results are ordered newest first, and the returned record shape includes outcome values and HTTP status. It does not state the retention window for 'recent', how cursor pagination terminates, or that this is a non-mutating read, which leaves real gaps for a tool with zero annotation coverage.

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 dense sentence that front-loads the resource and ordering, then lists the fields worth knowing. No filler or repetition. The colon-delimited field list is efficient rather than rambling, though the sentence fragment style is slightly clipped.

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, the description correctly spends its words enumerating return fields, which is the right allocation. However, for a six-parameter paginated list tool it omits how paging works in practice and how far back 'recent' reaches, leaving the agent to discover those by trial.

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%, with the q filter syntax (took:>200ms status:>=500 is:cold), kind/outcome enums, limit default of 20, and cursor semantics all documented in the schema. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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 names a specific resource and scope: recent function invocations, ordered newest first, and enumerates what each entry carries (trigger kind and cause, outcome, HTTP status, duration, error first line). That is far more concrete than a restatement of the name. It stops short of naming the sibling it differs from (functions_get_call for a single call, logs_search for log text), so it lands at 4 rather than 5.

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 or when-not-to-use guidance, and no sibling is named even though functions_get_call, functions_replay_call, and logs_search are obvious adjacent choices. The only implicit signal is 'recent', which hints at a recency-bounded listing, but nothing tells the agent how to page past it or what to do when it needs one call's full detail.

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 usefully discloses the return shape (outcome, status, response body, new call id) and that the original request/event is reused, but it does not warn that replay re-executes side effects or whether the original call record is altered — important for a mutation tool with zero annotation coverage.

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 well-formed sentence that front-loads the action and appends the return info. No filler, though the trailing clause about the returned id is slightly dense.

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 two-parameter tool with no output schema, the description compensates by naming the fields returned and pointing to functions_get_call for follow-up. The main remaining gap is behavioral: side-effect and idempotency implications of replaying are unstated.

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%, so both the id and maxBodyChars parameters are already documented in the schema. The description adds only the implicit note that the payload comes from the recorded call rather than a parameter; baseline 3 applies.

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 and resource: re-run a recorded function call with the original request or event. It also names the follow-up sibling (functions_get_call) for retrieving the result. It does not distinguish itself from functions_invoke, which an agent could easily confuse with replay.

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 phrase 'after a fix, say' implies the usage context (replaying once a bug or config issue is corrected), but there is no explicit guidance on when to use this versus functions_invoke or eventarc_replay_event, and no exclusions or prerequisites are given.

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 supplied, so the description carries the burden. "Count" adequately implies a read-only, non-destructive aggregation, but it says nothing about the default time window when `from`/`to` are omitted (a meaningful behavioral default for an 8-param, all-optional tool), nor about facet cardinality or result-size limits.

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 that front-loads the core verb and resource, then appends the grouping dimensions and the workflow motivation. Dense but waste-free; the facet list is slightly crammed into one clause rather than being broken out.

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 conveys the aggregation axes and the intent, partially compensating for the absent output schema. However, for a tool with no annotations and no output schema, it omits the shape of the result (bucket/value/count triples) and the default time range, both of which an agent needs to interpret counts 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?

Schema coverage is 100%, so the baseline is 3, but the description earns more by revealing the output grouping dimensions. Notably, "codebase" and "extension instance" appear nowhere in the input schema, so the description is the only place an agent learns these aggregation axes exist.

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?

"Count the log lines matching a filter" is a specific verb+resource, and the description enumerates the grouping dimensions (level, service, function, codebase, extension instance, kind), which separates it from a plain search. It does not name `logs_search` explicitly, so sibling differentiation is implied via "before reading them" rather than stated.

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?

"to see where errors and warnings come from before reading them" establishes a clear place in the workflow: aggregate first, read individual lines afterwards. It stops short of naming `logs_search` as the follow-up tool or saying when not to use this one (e.g., when you need message text), so it is clear context without explicit 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?

No annotations are supplied, so the description carries the burden; it does disclose one genuinely useful behavioral trait — it returns the newest matching lines in oldest-first order. However, it says nothing about default result size (only in the schema), whether logs are ephemeral or cleared elsewhere, or how 'before' interacts with 'from'/'to' for paging.

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 dense sentence with the resource scope front-loaded and the return ordering appended. Nothing is wasted, though the phrase "returns the newest matching lines, oldest first" is slightly compressed and could read ambiguously at first pass.

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 ten-parameter, fully self-documenting, read-only search tool with no output schema, the description adequately covers scope and result ordering. Remaining gaps — pagination interaction and log lifecycle — are minor given the schema already explains cursor and limit semantics.

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 100%, so all ten parameters are already documented with their own syntax examples (console grammar for q, relative time forms for from, cursor semantics for before). The description only restates the filter dimensions already present in the schema, adding no meaning beyond it — baseline 3 applies.

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?

Uses a specific verb ("Search") plus a well-scoped resource ("the suite's log") and enumerates the dimensions it can filter on, so an agent knows immediately this is a cross-emulator/function log query. It does not name or distinguish itself from the sibling logs_facets, so the boundary with that tool is left implicit.

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 implied by the scope statement (searching console output across emulators and functions), but there is no explicit when-to-use guidance, no mention of when to prefer logs_facets, and no note about logs being cleared by emulators_clear. An agent must infer the selection criteria.

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 usefully discloses what the response contains (delivery type, filter, dead-letter topic, backlog) and that detached subscriptions are included, but says nothing about pagination, ordering, cost on large projects, or required permissions.

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?

One dense sentence with the scope and return fields front-loaded and no filler. It is a fragment rather than a sentence, but nothing in it 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?

For a single-optional-parameter read tool with no output schema, the description covers scope, filtering semantics via the schema, and the key fields returned. Only pagination and permissions remain unaddressed, which is a minor gap.

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 100%, so the baseline is 3; the description adds genuine meaning by making clear that omitting the 'topic' parameter returns subscriptions across all topics plus detached ones, which the schema does not state.

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 names the resource (Pub/Sub subscriptions), states the scope ('every topic, and detached ones'), and enumerates the payload fields (delivery type, filter, dead-letter topic, backlog). It is clearly distinct from pubsub_list_topics by resource, though it never names that sibling 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?

Listing subscriptions is the implied use and the optional 'topic' filter is self-explanatory from the schema, but there is no explicit when-to-use guidance, no mention of pubsub_list_topics or pubsub_peek as alternatives, and no note about when to omit the filter.

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 must carry the behavioral burden, and it does disclose the shape of the response: counts, subscriptions, and triggered functions, with schedule topics included. It never states that this is a read-only, side-effect-free listing, nor anything about ordering, pagination, or what an empty emulator returns.

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 dense sentence with no filler, front-loaded on the resource and immediately followed by the returned fields. The trailing parenthetical about schedule topics is slightly awkward but earns its place by defining 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?

There is no output schema, so the description has to describe return values, and it does so only at a high level: field names without types or structure. For a simple zero-parameter lister this is close to adequate, but it leaves the agent guessing about the nesting of subscriptions and trigger functions.

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 and the schema is an empty object with additionalProperties false, so there is nothing for the description to clarify. The baseline for a no-parameter tool applies.

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 names the resource precisely (the Pub/Sub emulator's topics) and enumerates what comes back: published counts, subscriptions, and the functions each topic triggers. It also marks its scope against sibling listing tools by noting that schedule topics are included. It loses a point only because it is a noun phrase with no explicit verb like 'list'.

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 and no mention of alternatives such as pubsub_list_subscriptions, pubsub_peek, or schedules_list. The scope note about schedule topics hints at coverage but does not tell an agent which sibling to choose for which question.

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 and does so well on the critical trait: no pulling, leasing or acking, so message state is not mutated. It also names the returned per-message fields, giving the agent a substitute for a missing output schema. It omits permission requirements and any note on cost or rate limits for large backlogs.

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?

One sentence, front-loaded with the verb and resource, and the non-destructive qualifier arrives before the payload list. Nothing redundant.

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 5-parameter read tool with no annotations and no output schema, the definition covers the essentials: it says the operation is non-mutating and enumerates what is returned for each message. Pagination is only implied via the cursor parameter in the schema, and permissions/limits are unaddressed, keeping it below 5.

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%, so full/limit/state/cursor/subscription are all already documented with their defaults and bounds. The description reinforces that per-message state, attempts, attributes and data are surfaced, but adds no new syntax or format meaning beyond the 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 ('peek') and resource ('subscription's backlog'), plus the scope constraint 'in delivery order'. It distinguishes itself from the write-side siblings (pubsub_publish) and from a consuming subscriber by explicitly saying it does not pull, lease or ack.

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 makes clear this is the inspection path rather than a consumption path, which implicitly tells an agent to use it for read-only backlog diagnostics instead of a pull/ack flow. It does not name a specific sibling alternative or state exclusions such as 'not for draining a subscription' explicitly, so it falls short of a 5.

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 exist, so the description carries the full burden. It usefully discloses encoding behavior — strings pass through as-is, other JSON is sent as text and base64-encoded on the wire — but says nothing about failure modes, whether the emulator must be running, ordering-key semantics, or what a successful publish returns.

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 the core action front-loaded and the encoding caveat attached via a colon. Dense but readable, with no filler; slightly crowded by stacking three ideas into one clause.

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 four-parameter mutation tool with no annotations and no output schema, the description covers the data-encoding nuance but omits operational context an agent needs: emulator availability, ordering-key behavior, and result/error shape.

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 100%, so the baseline is 3. The description does add real meaning for the 'data' parameter (how non-string JSON is serialized and base64-encoded on the wire), but leaves 'attributes' and 'orderingKey' entirely to the schema's one-line descriptions.

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 and resource ('Publish a message to a Pub/Sub emulator topic'), which distinguishes it from eventarc_publish and pubsub_peek by naming the Pub/Sub emulator target. It stops short of explicitly contrasting itself with the sibling publish tool, so it is clear but not fully differentiated.

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 beyond the implied 'you want to publish a Pub/Sub message'. Nothing tells the agent when to prefer this over eventarc_publish, how to discover a topic name (e.g. via pubsub_list_topics), or any prerequisites such as the emulator being active.

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 supplied, so the description carries the full behavioral burden. It does well to declare 'Nothing is written' and to name the return payload (verdict, deciding rule line, evaluated expressions), but it never says what happens on a compile error, whether an emulator must be running, or how draft evaluation differs in cost or side effects.

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 that opens with the purpose and closes with the safety clause and return shape. It is dense with semicolons but every clause carries information; minor cost is that enumerating all five methods makes it slightly harder 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?

For a 17-parameter tool with no output schema and no annotations, the description covers the essential gaps: what is simulated, that nothing is persisted, and what comes back. Remaining omissions are error behavior and any prerequisite about the emulator being active.

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% across all 17 parameters, so the schema already documents uid, source, existing, object and the rest. The description only gestures at the uid/claims/idToken axis ('as a given user or unauthenticated') and the source/draft axis; it adds little beyond what the schema states.

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 and resource: evaluate rules in force or a draft against a hypothetical request, enumerating the five methods and the Firestore/Storage targets. That framing separates it cleanly from siblings like rules_get (fetch source) and rules_list_denials (post-hoc denials).

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 conditional 'whether a request would be allowed' plus 'in force (or a draft)' makes the use case clear, and 'Nothing is written' signals it is a dry-run rather than an actual operation. It stops short of naming alternatives, e.g. pointing at rules_get when the goal is to read the rules text rather than evaluate them.

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 supplied, so the description carries the full behavioral burden. It discloses that the result includes source, enforcement status, file, and problems, and 'get'/'in force' imply a read, but it does not explicitly state read-only behavior, permissions, or side effects.

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. The parenthetical return summary is dense but earns its place; there is only minor awkwardness in phrasing.

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 simple three-optional-parameter getter, the description covers purpose and returned metadata. With no output schema, the return summary is useful, though safety and permission context remains thin.

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 100% and already documents bucket, the service enum with default both, and the database default. The description maps Firestore rules to a database and Storage rules to a bucket, but adds no syntax or default details beyond the 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?

The description names the resource (Security Rules) and scopes it to Firestore database rules and Storage bucket rules, including returned metadata. It does not explicitly contrast with siblings such as rules_evaluate or rules_list_denials, so the distinction must be inferred from 'in force'.

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 explicit when-to-use or when-not-to-use guidance is given, and no alternatives are named. The phrase 'in force' implies inspecting current rules, but the description does not route the agent away from rules_evaluate or rules_list_denials.

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 and discloses important behavioral traits: only app-client denials, admin/owner requests skipped, ordering newest last, and what explain adds. It omits whether the operation is read-only/safe, any permission requirements, and pagination behavior beyond what the schema documents for limit.

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 densely packed sentence with semicolons; the key scope, exclusion, ordering, and explain behavior are front-loaded. Every clause adds useful information without 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?

For a six-parameter filtered list tool with no annotations and no output schema, the description covers the key behavioral nuance and explain mode. It leaves default limit and return shape to the schema, which is reasonable, though a brief note on output format would improve completeness.

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 100%, so every parameter is already documented in the input schema. The description only elaborates slightly on explain (returning the rule lines that denied each request), adding marginal meaning beyond the schema's own text.

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 and resource (list recent requests denied by Security Rules) and adds scope qualifiers: app clients only, admin/owner requests skipped, newest last. It does not name or distinguish from any sibling tool, so the agent must infer its relationship to rules_evaluate or logs_search.

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 for investigating denied requests and notes that admin/owner traffic is excluded, giving useful context. However, it gives no explicit when-to-use guidance versus alternatives such as rules_evaluate or logs_search, and no when-not-to-use conditions.

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 supplied, the description carries the full disclosure burden, and it does add useful detail about the returned content (expression, time zone, next runs, paused state, latest run delivery records). It does not state that the operation is read-only in behavioral terms, nor mention pagination, result limits, or whether 'latest runs' is bounded. Reasonable but incomplete for an annotation-free tool.

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, dense clause with no filler, front-loading the resource and then the fields. It is a sentence fragment lacking an explicit verb, which slightly weakens immediate comprehension but costs no extra tokens.

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 zero-parameter list tool with no output schema, the description must explain what comes back, and it does so at the field level. It omits the scope of the listing (current project? emulator target?), any pagination or size behavior, and the distinction from schedules_run, leaving gaps an agent would have to discover empirically.

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, so the baseline is 4; there is nothing for the description to disambiguate at the input level. The description instead spends its words on output shape, which is the only meaningful semantic surface here.

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 names the specific resource (scheduled functions, citing onSchedule and pubsub.schedule) and enumerates the fields surfaced: expression, time zone, next runs, paused state and latest runs with delivery. The verb 'list' comes only from the tool name, but an agent can tell this is an enumeration of schedules rather than an action. Differentiation from the sibling schedules_run is implied by the name but never stated in the text.

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 versus alternatives such as schedules_run or functions_list, nor any mention of prerequisites or exclusions. The only usage signal is the implicit read-only 'list' framing.

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, and it does disclose the core side effect: a real publish to the schedule topic that will cause the function to execute, not a simulation. It does not say whether the call waits for the run, whether it is recorded separately from scheduled runs, or what permissions are required.

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; the mechanism and the 'report the run' outcome are packed efficiently. The trailing clause is slightly vague but costs little.

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 one-parameter tool with no output schema, the description covers what happens and hints at a reported result, which is close to adequate. It leaves open the response shape ('report the run') and whether execution is synchronous, gaps an agent may care about before triggering real execution.

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 100% and the schema already explains both name forms and the region-qualified id example. The description adds nothing about resolving ambiguous names or region defaults, so the baseline 3 applies.

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 and resource ('Run a scheduled function now') and explains the mechanism ('publish one tick to its schedule topic, as Cloud Scheduler would'), which separates it from functions_invoke and tasks_run. It stops short of naming those alternatives explicitly, so the differentiation is inferable rather than stated.

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?

'Run now' implies on-demand manual triggering, which is useful implicit guidance. However, it never says when to prefer this over functions_invoke or tasks_run, nor any preconditions (emulator running, schedule existing, function deployed).

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 load and does disclose the most important behavior: it refuses to overwrite an existing destination unless overwrite is true, which is the key safety trait for a copy tool. It also notes cross-bucket capability. It omits whether folder copies are recursive, whether missing destination parents are created, auth requirements, and return 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?

A single front-loaded sentence that leads with the action and resource, then layers in the folder convention and the overwrite guard. No filler wording to remove.

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 5-parameter tool with full schema coverage and no output schema, the description covers the operation, the folder form, cross-bucket scope, and the overwrite guard. It falls short only on recursive-folder semantics and what the call returns, which would help an agent calling it on large prefixes.

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 100% and every property is documented in the schema itself, so the baseline is 3. The description restates the folder-trailing-slash convention for path/to and the same-or-other-bucket idea already covered by bucket/toBucket, adding no syntax or format detail beyond the 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 (Copy) and resource (Storage object or folder), plus scope: same or another bucket. It does not explicitly distinguish itself from the sibling storage_move, but copy-vs-move is clear enough from the wording that an agent can pick correctly.

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 description makes clear this duplicates rather than relocates data, and that folders ending in / are valid sources. There is no explicit 'use this instead of storage_move when...' routing, and no stated preconditions (e.g., destination folder existence).

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, and it does the most important work by flagging destructiveness and disclosing the non-obvious recursive folder behavior that the schema alone would not signal as dangerous. It omits irreversibility, permission requirements, and whether a missing path errors or silently succeeds, which keeps it short of full 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?

A single sentence, front-loaded with the destructive warning and then the two scopes. Nothing is padded and the highest-risk information comes first.

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 destructive mutation tool with no annotations and no output schema, the description covers the key hazard but not the operational details an agent needs, such as whether deletion of a folder is atomic, what happens on a missing object, or what the return value reports. Adequate but with clear gaps.

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%, so both parameters are already documented, including the trailing-slash folder convention and the default bucket. The description restates the folder-path semantics for the required parameter but adds no format details, constraints, or examples beyond the schema, so this is baseline.

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 gives a specific verb (delete) and resource (Storage object) and clearly defines two operating modes: single object, or every object under a folder when the path ends in '/'. It does not name or contrast with the nearest sibling (e.g., firestore_delete or storage_move) but the resource is unambiguous.

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 'DESTRUCTIVE' prefix signals this is a last-resort operation, and the folder form is explained, but there is no explicit 'use only when…', no suggestion to call storage_list or storage_get_metadata first to verify targets, and no note on what happens if the path does not exist.

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, and it does deliver one genuinely useful behavioral fact: a missing object returns exists:false rather than erroring, which shapes how the agent handles misses. It lists the returned metadata fields, but says nothing about read-only semantics, required IAM permissions, per-object vs per-bucket cost, or whether tokens/metadata are redacted.

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, and the returned-field list is packed efficiently. The fragment construction and the dangling 'or exists:false' clause make the grammar slightly ambiguous, costing it a point on structure rather than length.

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 two-parameter read tool with no output schema, the description covers the essentials: which object, which fields come back, and what happens when it is absent. Only permission and read-only expectations are unaddressed, which is a minor gap at this complexity.

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%; both 'path' (with an example) and 'bucket' (with a default) are fully documented in the schema. The description adds no path syntax, bucket-resolution, or cross-bucket guidance beyond that, so the baseline 3 applies.

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 names a specific resource ('one Storage object') and enumerates the returned fields (content type, size, timestamps, custom metadata, download tokens), so an agent knows this is a per-object metadata read. It stops short of naming how it differs from siblings like storage_read or storage_list, and the telegraphic fragment style ('The metadata of... or exists:false') lacks an explicit verb.

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 an implicit usage hint in 'or exists:false', telling the agent this doubles as an existence probe for a single known path. However, no alternatives are named — nothing says to prefer storage_list for discovering objects or storage_read for content — and no preconditions are stated, so the when-to-use reasoning is left 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 supplied, so the description carries the full burden. It does disclose a meaningful behavior beyond the schema: the listing is one level deep and returns both objects and folder prefixes, which is the key semantic an agent needs. It omits permissions/auth expectations and any note that results are paged rather than exhaustive.

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 filler, and the most decision-relevant clause (one level, not recursive) is placed where it will be read first.

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?

All four parameters are optional and fully described in the schema, and no output schema exists, so most of what an agent needs is covered elsewhere. The description still leaves gaps for a read tool with zero annotations: no statement of auth requirements, no note that results are paginated via pageToken, and no indication of how folders versus objects are distinguished in the response.

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%, so bucket, prefix, pageToken and maxResults are already documented, including the trailing-slash normalization and the default page size. The description only reinforces that prefix scopes the listing; it adds no format or default details beyond the schema, so the baseline 3 applies.

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 clear verb and resource: 'List Storage objects and folder prefixes under a prefix.' The added scope '(one level, like listAll)' distinguishes it from the recursive/metadata siblings such as storage_get_metadata and storage_read, 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?

Usage is implied rather than stated: 'one level, like listAll' tells the agent this is a shallow browse, not a recursive walk or a content read. There is no explicit when-to-use/when-not guidance and no named alternatives to choose instead.

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 supplied, the description carries the full disclosure burden, and it does add one important behavioral fact: the operation refuses to overwrite unless overwrite is true, which warns the agent about a non-destructive default. However, it omits whether the source is removed, whether folder moves are recursive, required permissions, and what happens to an existing destination tree when overwrite is enabled.

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 filler, front-loading the action and entity before the conditions. Every clause (rename, folder convention, cross-bucket scope, overwrite protection) contributes distinct information.

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 five-parameter mutation with no annotations and no output schema, the description covers the essential semantics of source, destination, bucket scoping, and overwrite protection. It could still be richer about source removal behavior, recursive folder handling, and the shape of the result, but an agent has enough to invoke it 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?

Schema coverage is 100%, so every parameter already has its own description, and the description largely restates the folder-trailing-slash convention and the overwrite flag rather than adding new meaning. The 'refuses to overwrite' phrasing gives overwrite a concrete consequence, which is a modest value add over the schema wording 'Replace an existing destination'.

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 names a specific verb and resource ('Move (rename) a Storage object or a folder') and scopes it to the same or another bucket, which distinguishes it from the sibling storage_copy tool by move semantics alone. The parenthetical clarifies that folder paths are signaled by a trailing slash, so an agent knows exactly what entity it is acting on.

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?

It establishes clear context for use: moving within or across buckets, and that existing destinations are protected unless overwrite is true. It stops short of naming alternatives (e.g., use storage_copy to duplicate instead of move, or storage_delete for removal) or stating when a move is inappropriate, so it lacks explicit exclusion 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?

No annotations are supplied, so the description carries the full burden. It does well on the payoff shape: it discloses the text-vs-base64 decision, the maxBytes cap, and that 'truncated' signals more content remains. It says nothing about error behavior for missing objects, permission requirements, or whether reads are counted/rate-limited — gaps that matter for a tool with zero annotation coverage.

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 the core action and the return-value contract front-loaded, then truncation semantics. No filler, no repetition of the tool name, and every clause adds information.

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 simple four-parameter read with a fully described schema and no output schema, the description covers the one thing the schema cannot: the actual return shape (inline text vs base64 plus a truncation flag). Only the missing-object and permission behavior keep it from being 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?

Schema description coverage is 100%, with enums and bounds already documented on every parameter, so the baseline of 3 applies. The description reinforces maxBytes and the encoding outcome but adds no syntax or format detail beyond what the schema states.

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 and resource ('Read a Storage object's content') and immediately describes what comes back (text inline for textual types, base64 otherwise). This implicitly separates it from storage_get_metadata and storage_list, though it never names those siblings to make the distinction explicit.

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 implied by the purpose — you call this when you need the bytes of an object rather than its metadata — but there is no explicit 'use this instead of storage_get_metadata when...' guidance, and no mention of what happens if the path does not exist. Adequate but leaves routing 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?

With no annotations, the description carries the full burden and does meaningful work: it discloses that existing objects are replaced, that security rules are skipped ('as the Admin SDK would'), and that finalize triggers fire as a side effect. It omits auth/permission requirements and any size or content limits, and says nothing about what the call returns.

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 dense sentence that front-loads the action and replacement semantics, then parenthesizes the runtime behavior. Nothing is redundant and no sentence 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?

For an 8-parameter mutation tool with a nested customMetadata object, no annotations, and no output schema, the description covers the essential behavior (replacement, rule bypass, trigger side effects) well. The remaining gap is the absence of return-value information, which the description could have supplied since no output schema exists.

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 100%, so every parameter including ifNotExists, cacheControl, and customMetadata is already documented in the schema. The description only reinforces the text/base64 source choice and metadata fields, adding little semantics beyond what the structured fields provide — baseline 3 applies.

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 — upload/create-or-replace a Storage object — and names the accepted content sources (text or base64 bytes) plus accompanying fields. It is clearly distinguishable from storage_read, storage_get_metadata, and storage_copy without opening the schema, though it never names those siblings 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?

Usage is only implied: this is evidently the write counterpart to the other storage_* tools, and 'create or replace' hints at when replacement is acceptable. There is no explicit when-to-use vs. alternatives guidance (e.g., use storage_copy to duplicate an object, set ifNotExists to avoid clobbering) and no stated prerequisites.

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 supplied, so the description bears the full burden. It usefully discloses the shape of the result (queues with pending/running counts, and the tasks within them), which is real behavioral value. However, it never states that this is a non-mutating read, says nothing about ordering or pagination beyond the limit parameter, and does not mention how many queues are returned or what happens with zero queues.

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?

It is a single sentence with no filler, and the primary resource (queues) is front-loaded ahead of the filtering behavior. The semicolon clause is slightly compressed to the point of feeling telegraphic, 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 three optional, fully documented parameters and no output schema, the description does the one thing that matters most: it sketches the return contents (queues with counts, tasks within them) that the schema cannot express. Missing are read-only confirmation and any note about result volume, which for a list endpoint without an output schema would have been worth one extra clause.

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%, so the baseline is 3. The description reinforces the semantics of queue (scope to one queue) and state (restrict to one state), but adds no syntax, format, or defaulting detail beyond what the schema already documents. The one nuance it could have clarified — that limit is per queue rather than a global cap — is only in the schema, not the description.

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 names a concrete verb-resource pairing: it returns Cloud Tasks queues (with pending and running counts) plus the tasks inside them. That is more specific than the tool name alone and tells the agent the return payload includes aggregate counts as well as task entries. It does not explicitly contrast itself with siblings like tasks_stats or tasks_run, so it stops short of a 5.

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 clause 'with queue, only that queue's tasks, optionally in one state' conveys that the queue parameter narrows scope and state further filters. There is no explicit statement of when to call this instead of tasks_stats (counts only) or tasks_run (execution), which are the obvious alternatives in the sibling list.

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 disclosure burden. It does add one genuinely useful behavioral fact — dispatch is asynchronous, sent on the next tick — but says nothing about permissions required, whether the task is removed, retry/failure behavior, or what happens if the task already ran.

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 the action and the critical timing distinction front-loaded, and the parenthetical adds needed precision about 'now' meaning the next tick. Nothing is wasted and nothing important is buried.

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 two-parameter mutation tool with full schema coverage and no output schema, the definition covers what an agent needs to invoke it correctly, including asynchronous timing. It is only slightly short on outcome information (e.g., whether dispatch confirmation or a task reference is returned).

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%: both 'queue' and 'id' are documented in the schema, including that 'id' comes from tasks_list. The description adds no additional meaning about parameter format or constraints, so the baseline of 3 applies.

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 gives a specific verb ('Dispatch') and resource ('one waiting Cloud Tasks task'), plus the key scope distinction that it fires now rather than at the scheduled time. It is clearly distinguishable from tasks_list and schedules_run by implication, though it never names them.

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 phrase 'one waiting task' and 'instead of at its schedule time' implies when to use it (forcing early execution of a pending task), but there is no explicit guidance on when not to use it, prerequisites, or which sibling to consult for task discovery. Usage is inferable rather than stated.

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 does not state that this is a read-only operation, whether it targets a running emulator instance, or what the statistics contain, leaving the agent guessing about side effects and output.

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 sentence with the resource front-loaded. The parenthetical '(queueStats)' is minor API-mapping noise but harmless and aids identification of the upstream endpoint.

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?

There is no output schema and no annotations, so the description is the only source of information about what the statistics include. It says nothing about returned fields, whether an emulator must be running, or how queue scope is determined.

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, so there is no parameter meaning to convey; the baseline for a parameterless tool applies.

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 names a specific resource (queue statistics) for a specific target (the Cloud Tasks emulator) and ties it to the underlying queueStats call. It is clear what the tool returns, though it does not distinguish itself from siblings like tasks_list or tasks_run.

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 call this versus tasks_list or tasks_run, and no prerequisites or exclusions are stated. The agent must infer its use from the name alone.

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