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

Annotations already indicate a non-readOnly, non-idempotent, non-destructive operation. The description adds a small behavioral detail—'immutable version' and 'manifest entry point'—but does not disclose side effects such as creating a deployment resource or requiring an existing version. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single compact sentence with no filler and the key action is front-loaded. It is slightly under-specified, but as far as conciseness itself, it wastes no words.

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 mutating operation with no output schema and no schema-level parameter descriptions, the definition is too thin: it omits preconditions (an existing version), what the returned deployment looks like, and how this deployment relates to the script. Sibling deployment tools make that context important.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description should explain the parameters; it only loosely hints at versionNumber via 'immutable version' and manifestFileName via 'manifest entry point'. scriptId and description are left entirely unexplained, which is a significant gap.

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 ('Deploy') and identifies the artifact as an immutable version with a manifest entry point, making the operation recognizable. It does not explicitly mention 'deployment' or differentiate from create_version, but the intent is clear from the tool name and the action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to call this tool versus create_version, update_deployment, list_deployments, or the prerequisite that a version must already exist. The description only states the action, leaving the agent to infer context from sibling names.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description adds a small but useful behavioral note about preserving the returned scriptId for future use. However, it does not disclose other behavioral aspects like authentication requirements, rate limits, or what happens on failure. The description adds some context beyond annotations but not substantial detail.

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 extremely concise, consisting of two short sentences with the primary action front-loaded. Every word adds value, and the instruction about the returned scriptId is a necessary operational detail. There is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a create operation with two parameters and no output schema, the description covers the basic purpose but lacks details on parameter semantics, return value format (beyond mentioning scriptId), and any side effects or constraints. The annotations cover safety (not read-only, not destructive), but the description does not fully equip an agent to call the tool correctly without additional information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain the 'title' or 'parentId' parameters beyond the phrase 'standalone or container-bound,' which only vaguely hints at the role of parentId. With no parameter documentation in the schema or description, the agent is left to infer parameter meaning, which is inadequate for a tool with a required parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create') and the resource ('Apps Script project'), and distinguishes between standalone and container-bound variants. This differentiates it from sibling tools like apps_script_get_project or apps_script_update_content, which have different verbs and purposes.

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 when to use this tool (when creating a new project) but does not explicitly state when not to use it or mention alternatives. It does not provide exclusions or prerequisites, such as needing an existing container for container-bound projects. The instruction to 'Preserve the returned scriptId' hints at a follow-up action but does not guide the agent on selecting this over other tools.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds the key behavioral trait 'immutable' and 'snapshot of HEAD', which clarifies that this creates a permanent, non-modifiable version. This adds value beyond annotations by explaining the immutability and source.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the core action and key trait (immutable). No wasted words.

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 create operation with 2 parameters and no output schema, the description is mostly adequate. However, with 0% schema coverage, it doesn't explain what the description parameter is for or what the response contains. The immutability trait is useful but the tool could benefit from noting that this is a versioning operation tied to a specific scriptId.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It mentions 'HEAD' but doesn't explain the scriptId parameter or the optional description parameter. The description adds no meaning beyond the schema's basic property names and types.

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 'Create an immutable version snapshot of HEAD' clearly states the verb (create), resource (version snapshot), and source (HEAD). It distinguishes from siblings like apps_script_list_versions and apps_script_get_version, though it doesn't explicitly name 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 description implies usage: creating a version snapshot of the current HEAD. It doesn't explicitly state when to use this vs alternatives, but the context of versioning is clear. No exclusions or alternative tool names are provided.

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

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

Annotations already flag destructiveHint=true, so the description's job is to add context. It does exactly that by specifying that the live URL is broken and that the deletion is permanent. This goes beyond the annotation and gives the agent a concrete understanding of the impact.

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 is immediately informative and front-loaded with the action and the key consequence. Zero verbosity and every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive operation with three required parameters including a confirmation flag, the description is too lean. It fails to explain the mandatory confirm=true requirement, which is critical to safe invocation, and provides no guidance on error handling or idempotency (even though annotations give idempotentHint=false). The lack of parameter explanation makes it incomplete for an agent to execute 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 0%, so the description must compensate by explaining the parameters. It entirely omits the purpose of 'confirm' (which is const true and presumably a safety gate) and does not clarify what scriptId and deploymentId refer to. An agent could not confidently construct a valid call without schema inference.

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 a clear resource ('deployment') and adds a concrete consequence ('break its live URL'). This unambiguously distinguishes it from the other deployment-related siblings (create, update, list, get).

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 clearly implies this is the tool for permanent deletion, and the sibling list makes the alternative operations obvious. However, it does not explicitly state when NOT to use it or mention any prerequisites (e.g., needing scriptId/deploymentId), so it stops short of the top tier.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the description adds the concept of HEAD vs immutable version, reinforcing the read-only behavior. It does not describe error cases or version handling beyond the schema, but does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no filler. It states the action, resource, and version distinction efficiently.

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 strong annotations, the description covers the core purpose, but omits what the returned content looks like (since there is no output schema) and does not explicitly state how the optional versionNumber behaves when omitted. This is a minor but noticeable 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 description coverage is 0%, so the description must carry the parameter meaning. It implies versionNumber picks a version, but never explicitly describes scriptId or that versionNumber is optional. This is insufficient compensation for the lack of schema 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 ('Read') and resource ('all Apps Script project files'), and distinguishes HEAD from immutable versions, which separates it from sibling tools like apps_script_get_project (metadata) and apps_script_get_version (version details). The scope 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 explicit guidance on when to use this tool over alternatives like apps_script_get_project or apps_script_get_version. The description implies it is for file content retrieval, but it does not state exclusions or remind the agent to use a version-specific tool if only metadata is needed.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only nature is established. The description adds no extra behavioral detail (e.g., auth, response shape), but it does not contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one short sentence with no filler, and the core operation is front-loaded. It is appropriately concise for a simple getter, though it sacrifices useful 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?

For a tool with two required string parameters and strong read-only annotations, this is close to minimally viable. However, without an output schema the description does not clarify what the deployment object contains, and there is no mention of when to select this over sibling deployment tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not mention scriptId or deploymentId or clarify how to obtain/fill them. The parameter names are self-explanatory, which prevents a score of 1, but the description fails to compensate for the missing schema 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?

The description identifies a specific verb ('Get') and resource ('one Apps Script deployment'), which is clear enough to distinguish from create/update/delete and from list_deployments. It does not explicitly name the alternatives, so it stops short of the strongest sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given for when to use this tool versus apps_script_list_deployments, get_project, get_version, or other siblings. 'Get one' implies a single deployment lookup, but there is no explicit when/when-not guidance or alternative recommendation.

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?

The annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, openWorldHint=true, destructiveHint=false), so the bar is lower. The description adds the metric categories returned (execution, user, failure), which is useful context, but it does not disclose aggregation behavior, time-range semantics, or error behavior for an invalid scriptId. 'Get' is consistent with readOnlyHint=true, so there is no contradiction.

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 zero wasted words — verb first, then resource, then the three metric categories. It is appropriately sized for what it conveys and front-loads the most important 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?

Despite strong annotations, the description leaves significant gaps for a 3-parameter tool with no output schema and zero parameter descriptions. An agent cannot determine what deploymentId does, how granularity affects the result, or what the response looks like. The metric categories are helpful, but the description is thinner than the task requires.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for all three parameters but does not. Nothing explains what deploymentId filters, what WEEKLY vs DAILY granularity means for the returned data, or why scriptId is required beyond the schema's minLength:1. The phrase 'for an Apps Script project' only loosely connects to scriptId.

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 ('Get') and a specific resource ('execution, user and failure metrics for an Apps Script project'), and it names the distinct metric categories it returns. No sibling tool deals with metrics — siblings cover running functions, listing processes, content, versions, and deployments — so an agent can identify this tool's niche immediately 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?

No guidance is given on when to use this tool versus alternatives. It does not mention when to prefer it over apps_script_list_processes or apps_script_list_script_processes for execution-related data, nor does it state preconditions such as whether a deployment or version must exist before metrics are available.

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

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

Annotations already mark the call as readOnly, idempotent, and non-destructive, so the safety profile is clear. The description adds no further behavioral detail (e.g., return shape or side effects) but does not contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, complete sentence with no filler. The key action and object are front-loaded, making the description maximally concise.

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?

No output schema exists, so the description should explain what metadata is returned; 'metadata' is vague. There is also no information about auth prerequisites or edge cases, leaving meaningful gaps for a tool called by an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no meaning beyond the param name scriptId. While minLength is the only constraint, the description does not explain what the scriptId represents or how to obtain it.

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 and resource: 'Get Apps Script project metadata' clearly identifies the operation. It is not a tautology, but it doesn't explicitly differentiate from sibling tools like apps_script_get_content or apps_script_get_metrics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided for when to use this tool versus sibling tools such as apps_script_get_content or drive_list_apps_script_projects. The agent is left to infer the appropriate selection from the tool name 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds 'immutable' which describes the version resource, not the tool's behavior. It does not add context like auth requirements, rate limits, or side effects, but given the annotations, the bar is lower. No contradictions exist.

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 zero filler. It immediately communicates the action and resource, and the word 'immutable' adds a meaningful qualifier without bloat. Perfectly concise and well-structured.

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 getter with two required parameters and no output schema, the description is adequate but sparse. It does not mention the return value, but for a read operation, that may be inferred. It also fails to explain how to obtain the scriptId or how versionNumber relates to the list of versions. Given the simplicity, it is minimally sufficient, but a bit more context on parameters 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 description coverage is 0%, so the schema only provides names and types. The description does not explain what scriptId and versionNumber mean or where to find them. Although the parameter names are somewhat self-explanatory (scriptId likely refers to the script's ID, versionNumber is the version to fetch), the description provides no additional context, and the low coverage means the description should compensate, which it does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Get' and the resource 'immutable Apps Script version', which is a specific, singular entity. It distinguishes itself from sibling tools like apps_script_list_versions (which lists all versions) and apps_script_create_version (which creates a new one). The verb-resource pair 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?

The description implies usage: when you need a specific version by its versionNumber, use this tool. However, it does not explicitly state when to choose this over listing versions or when not to use it. There is no mention of alternatives or exclusions, so the guidance is implicit rather than explicit.

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?

The annotations already establish read-only, idempotent, open-world, non-destructive behavior. The description adds a meaningful behavioral trait beyond those annotations: it automatically follows pagination instead of returning only the first page. This adds practical context and does not contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one short, well-structured sentence. It front-loads the core purpose and adds one valuable behavioral detail without any 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 read-only listing tool with rich annotations, this is mostly adequate. However, maxPages/pageSize semantics and the exact meaning of 'entry points' are left to inference, and there is no output schema to clarify 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?

Schema description coverage is 0%, and the description does not explain scriptId, maxPages, or pageSize. The mention of pagination hints at page-related parameters, but it does not meaningfully describe the meaning or interaction of the three parameters.

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 ('List') and a specific resource ('deployments and entry points'). It clearly differentiates itself from the singular get_deployment sibling, which targets one deployment rather than listing 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?

No guidance is given on when to use this tool versus get_deployment, create_deployment, or other Apps Script list tools. The usage context is only implicit in the tool name, with no explicit alternatives or exclusions.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the authenticated-user scope, which is useful context, but does not disclose pagination, rate limits, or what data is returned. Since annotations carry the safety burden, a 3 is appropriate.

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 short sentence that is concise and front-loaded with the action and resource. However, it may be too terse given the need for parameter and sibling differentiation, but for its length it is well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is too minimal for a tool with three undocumented parameters and a potentially overlapping sibling. It does not explain return format, pagination, or what 'filters' refers to. Annotations cover safety, but the description does not provide enough operational context to use 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 0%, and the description only says 'with filters' without naming any parameter. It does not explain maxPages, pageSize, or userProcessFilter, leaving the agent with no additional meaning beyond the raw schema. The description fails to compensate for the lack of parameter documentation.

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 the authenticated user's Apps Script executions'. The scope is explicit. However, it does not differentiate from the sibling apps_script_list_script_processes, which likely targets a specific script's executions, leaving the distinction 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?

No guidance on when to use this tool versus the sibling list_script_processes or other tools. The description does not mention alternatives, exclusions, or conditions that would select this tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only scope ('for one script') and a filter option, providing no further behavioral context such as pagination behavior or result 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 front-loaded sentence that puts the action and scope before the filter mention, with no filler. It could include a pointer to the sibling tool, but as a concise purpose statement it is efficient.

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 tool with no output schema and zero schema descriptions, this is incomplete: the API filter syntax is not specified, pagination semantics are unstated, and the difference from apps_script_list_processes is left 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 0%, so the description must compensate but only hints at 'optional API filter syntax' for scriptProcessFilter. maxPages, pageSize, and scriptId receive no explanation beyond their names and schema constraints.

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 ('List') and resource ('executions for one script'), and the 'one script' scope distinguishes it from the broader apps_script_list_processes sibling. The 'optional API filter syntax' further identifies a distinguishing capability of this tool.

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 statement of when to use this tool over apps_script_list_processes or how the optional filter relates to other listing tools. The only usage hint is 'optional API filter syntax,' which is too vague to route an agent to the correct alternative.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to repeat those. It adds the behavioral detail of automatic pagination, which is not captured in the annotations. However, it doesn't mention other aspects like authentication requirements or rate limits, leaving gaps beyond what annotations cover.

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 extremely concise with just 8 words. It front-loads the core purpose ('List immutable versions') followed by the key behavioral note about pagination. No filler or redundant information detracts from its efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no output schema and 0% parameter coverage, the description is far too sparse to be complete. It doesn't explain what the returned versions look like, what information is included, or any details about pagination behavior beyond 'automatically following.' An agent would be left with significant unknowns about the response format and how the parameters affect results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for parameter documentation. The description mentions no parameters at all - not scriptId, maxPages, or pageSize. While the schema provides defaults and ranges, the description adds zero semantic value for parameters, making it difficult for an agent to understand what each parameter controls.

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 'List immutable versions' - a specific verb and resource. It distinguishes itself from related tools like apps_script_create_version and apps_script_get_version by focusing on listing, though it doesn't explicitly name alternatives. The resource scope is implied by the required scriptId parameter, but the description alone is somewhat generic without mentioning the script context.

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 use this tool versus alternatives like get_version or create_version. The only behavioral guidance is 'automatically following pagination,' which is about how it operates, not about selecting the right tool. No context about prerequisites or when this is the preferred choice is provided.

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

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

Annotations already declare readOnlyHint=false and openWorldHint=true. The description adds that it opens in the system browser, which is useful context, but doesn't disclose potential side effects like requiring authentication or that it launches an external application. It doesn't contradict the annotations, but adds minimal behavioral depth beyond them.

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, compact sentence with no wasted words. The core action and target are front-loaded, making it highly scannable.

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 tool with one parameter and no output schema, the description is adequate but leaves gaps. It doesn't clarify that opening is a read-only side effect (despite readOnlyHint=false) or that it requires an existing project ID. The agent can likely operate correctly, but additional context about the action's implications 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?

The single parameter scriptId has zero schema description coverage, and the description does not explicitly explain that scriptId is the project ID. While it's inferable from 'Open an Apps Script project', the description fails to directly map the parameter to the resource, leaving the agent to rely on the name and context. This is insufficient compensation for the 0% coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action (Open) and resource (Apps Script project) with a destination (system browser). It clearly differentiates from sibling tools like get_project or run_function, though it doesn't explicitly name an alternative. The verb and object are 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 is provided on when to use this tool versus alternatives. It doesn't mention that it's the appropriate choice for launching the editor UI, nor does it exclude use cases like retrieving project content. The agent must infer usage from the name and description 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?

Annotations already list destructiveHint=true and openWorldHint=true. The description adds that it is 'through an API-executable deployment' and warns of 'real external side effects', reinforcing the destructive nature. It provides some context beyond the annotations but does not delve into specifics like potential irreversible changes or confirmation 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?

The description is a single concise sentence with no fluff. It front-loads the core action and warning. However, it is so brief that it sacrifices essential detail, making it under-specified rather than appropriately concise for a tool of this complexity.

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 tool with five parameters, an output schema absent, and no parameter explanations, the description is severely incomplete. It fails to address the required 'confirm' argument, what 'devMode' does, or how 'parameters' are passed. The agent cannot properly assess risk or construct a correct 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?

Schema description coverage is 0%, so the tool description must explain the meaning of the five parameters (scriptId, functionName, confirm, devMode, parameters). It does not mention any of them, leaving the agent to infer from the schema alone. This is a critical gap for a complex, destructive tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (execute), the resource (a function through an API-executable deployment), and warns of side effects. It is distinct from sibling tools that manage projects, deployments, or content, and no confusion is possible.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for running existing functions via deployments, but it does not explicitly state when to use it versus alternatives or mention any prerequisites. The caution about side effects hints at careful use, but no exclusions or guidance on when not to use it 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?

Annotations already carry destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds valuable behavioral context beyond annotations: that merge mode preserves unmentioned files and the manifest, and that replace mode demands explicit appsscript JSON. This warns the agent about the non-destructive vs destructive nature of each mode and clarifies the difference in required input. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero waste. The most important distinction (merge vs replace) is front-loaded, and each clause carries meaningful operational information. There is no redundant repetition of schema fields or annotations.

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 with no output schema, the description covers the key behavioral distinctions and the critical precondition for replace mode. The only minor gap is that it doesn't explicitly mention what the tool returns after the update, but for an 'update' operation this is often not essential and annotations already convey the destructive nature. The notion of 'HEAD' may be domain jargon, but the sibling set (get_content, create_version, etc.) makes it clear this is the live, editable drafts.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does: it explains the meaning of the mode enum values (merge/replace) and ties the files parameter to a required appsscript JSON in replace mode. The scriptId parameter is self-evident from the tool name and context. The description doesn't explain file type/source object properties, but the schema itself is richly verbose there, so the added meaning targets the most ambiguous parameters (mode and files in context).

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 ('Update') and a specific, meaningful resource ('Apps Script HEAD'), which clearly distinguishes it from sibling tools like apps_script_get_content (read), apps_script_create_project (create), and apps_script_update_deployment (update an unrelated resource). The mention of HEAD indicates the live editable version, so the agent won't confuse it with version or deployment updates.

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 gives concrete guidance on the two modes: merge preserves unmentioned files and the manifest, while replace requires appsscript JSON explicitly. This effectively tells the agent when each mode is appropriate, though it doesn't explicitly contrast with alternatives (e.g., 'use get_content to read first'). Still, the mode-level decision is clearly scoped.

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

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

Annotations already signal readOnly=false and destructive=true, so the description is not required to restate those facts. It adds useful context that the deployment ID/URL is preserved and that the target version is immutable, but it does not disclose broader effects such as impact on running executions or permissions 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 focused sentence that front-loads the action and resource, then adds the key distinguishing outcome. Every word contributes meaning 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?

The description is too thin for a destructive mutation with five parameters, no output schema, and no parameter-level documentation. It omits practical details about parameter roles, prerequisites, and what the result of the operation looks like, leaving an agent to guess important invocation details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden of explaining the parameters. It only vaguely maps to deploymentId and versionNumber through 'existing deployment' and 'another immutable version'. It provides no guidance for scriptId, description, or manifestFileName, leaving those semantically under-specified.

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 ('repoint') with a clear resource ('existing deployment') and states the outcome ('another immutable version while keeping its deployment ID/URL'). This clearly distinguishes the action from creating, deleting, listing, or getting deployments among the sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies strong context: use this tool when you already have a deployment and want to change which immutable version it points to, while preserving its ID/URL. It does not explicitly exclude creating a new deployment or updating content, but the intended use case is clear enough.

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?

The description goes beyond the sparse annotations by disclosing that the tool opens a browser, uses PKCE with a one-shot loopback callback, and persists owner-only refresh credentials. This gives a clear picture of the side effects, although it does not mention failure modes or behavior when credentials already exist.

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 dense sentence with no waste. The most important behavioral details, browser opening and OAuth flow, are front-loaded before the credential store outcome.

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 core flow and credential-storing side effect are covered, but with no output schema the return behavior is undefined. The description also omits success/failure expectations, timeout behavior, and the relationship to auth_setup, leaving some uncertainty for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the tool description does not explain either profile or timeoutSeconds. The enum values hint at OAuth scope profiles, but an agent is left to infer what 'profile' controls and how timeoutSeconds influences the login flow.

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 action: open the system browser, run Google OAuth with PKCE, and store owner-only refresh credentials. This clearly communicates what the tool does and distinguishes it from auth_status and auth_logout, though it does not explicitly differentiate it from the similarly named auth_setup sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not state when to use auth_login versus auth_setup, auth_status, or google_workspace_request. It implies use during interactive login but provides no exclusions, prerequisites, or alternative 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, which the description aligns with by stating it revokes and deletes tokens. The description adds one useful behavioral detail—environment-provided tokens cannot be deleted—but does not describe other side effects or reversibility. Given the annotations cover the main safety concerns, this is adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no redundancy. The primary action is stated first, followed by a crucial limitation. Every word contributes value, and it is appropriately concise for a simple logout tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no parameters and no output schema, the description covers the essential action and a key limitation. It is sufficient for an agent to invoke it correctly, though it might benefit from noting that logout is destructive (already implied by the destructiveHint annotation). Overall, it is complete for its simplicity.

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 has no parameters, and the schema is empty with 100% coverage trivially. Per guidelines, a zero-parameter tool gets a baseline of 4, and the description does not need to explain parameter semantics further. It correctly focuses on behavior instead.

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 revokes stored Google authorization and deletes local tokens, using specific verbs and resources. It also adds the nuance about environment-provided tokens, distinguishing it from auth_login and auth_status without ambiguity.

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 tool is the logout counterpart to auth_login and auth_setup, but it does not explicitly state when to use it versus alternatives. It does provide a caution about environment-provided tokens, which is useful, but lacks explicit exclusion or alternative 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?

Annotations already flag openWorldHint=true and idempotentHint=false, and the description adds concrete side effects: it may open the Google Auth Platform Clients page and reads the Downloads folder for client JSON. It does not explain what gets written or changed, but given the annotations, the added context is useful.

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, front-loaded with the core action, and no filler. The conditional structure is compact and every clause adds meaning.

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 2-param, no-output-schema setup tool with external side effects, the description explains the happy-path flow but omits what happens after auto-detection, what the return value is, and how openBrowser=false changes behavior. It is adequate but has 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 0%, so the description must carry the parameter documentation. It connects clientFile to auto-detection from Downloads and implies openBrowser controls opening the page, but it does not specify clientFile format or the exact role of openBrowser. This is partial compensation only.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific action ('Auto-detect a Desktop OAuth client') and explains the fallback behavior (open the Google Auth Platform Clients page). This distinguishes it from auth_login, auth_status, and auth_logout, though it doesn't explicitly name any sibling or state the final configured state.

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 text gives an internal conditional (auto-detect; if absent, open page) but never tells an agent when to choose this tool over auth_login, auth_status, or auth_logout. There is no explicit 'use when...' or exclusion, so usage is only implied by the setup-focused phrasing.

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?

The description says the tool 'refreshes credentials', which is a mutating side effect, while the annotations declare readOnlyHint=true. This is an annotation contradiction. The agent receives conflicting signals about whether calling this tool can change state, so the description fails to add trustworthy behavioral transparency.

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 filler. Every clause adds relevant information: what is detected, and why credential refresh happens.

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 zero-parameter status tool, the description covers the main intent and behavior. However, there is no output schema and no explanation of what the returned status looks like, and the contradiction with readOnlyHint leaves the tool's side-effect profile unclear, creating a moderate completeness 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 has zero parameters, so the description cannot add parameter-level meaning. Per the baseline rule for 0-param tools, a score of 4 is appropriate; there is no semantic gap to compensate for.

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's purpose with a specific verb ('Detect') and resource ('OAuth client and token state'), and adds the purpose of credential verification. This distinguishes it from siblings like auth_login, auth_setup, and auth_logout, which perform different auth lifecycle actions.

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 conveys a clear context: use this tool to check/verify OAuth connection status. It does not explicitly name alternatives or exclusions, but the purpose is unambiguous enough for an agent to select it over login/setup/logout tools.

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

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

Annotations already establish read-only, open-world, idempotent, non-destructive behavior, so the description only needs to add context. It contributes the implementation detail that this uses Drive and that the Drive route has the unique ability to list projects, but it says nothing about pagination behavior, query semantics, or the shape of results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences, front-loads the primary action and resource, and adds a useful distinguishing contrast without redundancy. Every part contributes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only list-style operation with no required parameters and strong annotations, the description is minimally adequate. However, with no output schema and no mention of how query/maxPages/pageSize affect behavior, an agent lacks enough detail to predict what a call returns or how far it pages.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the three parameters, so the description should explain what query, maxPages, and pageSize mean. It does not mention any of them; the term 'Discover' only weakly implies that query is a search filter, leaving the agent to infer the Drive search syntax and paging behavior.

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 clear verb ('Discover') and a well-defined resource ('Apps Script project files in Google Drive'), and the second clause contrasts it with the Apps Script API, which differentiates it from the many apps_script_* sibling tools. An agent can tell this tool is for Drive-based listing rather than API-based operations.

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?

'Unlike Apps Script API, Drive can list projects' explicitly points to the condition for choosing this tool: when listing projects is needed, the Apps Script API-based path is unsuitable. It does not name a specific sibling tool or spell out a when-not-to-use case, so it falls just 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?

The description adds valuable behavior beyond annotations: hosts are allowlisted, Authorization headers are injected, and destructive methods require confirm=true. These are practical details an agent needs to call the tool safely and effectively, and they are consistent with the destructiveHint and openWorldHint annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences carry essential purpose, security constraints, and destructive-usage confirmation. Information is front-loaded and every sentence adds value with no 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?

The description covers the core safety and auth context well, which is critical for an arbitrary REST tool. However, there is no output schema and no mention of response format, error behavior, or an example request, so an agent may be unsure what to expect from the request and how to handle failures.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but it only clarifies the confirm parameter. It does not explain how to construct the url, how query and body are serialized, or what method values imply beyond the schema's enum and defaults, leaving a significant gap.

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 identifies this as a generic escape hatch for Google Workspace REST APIs not covered by dedicated tools. It distinguishes itself from the sibling tools by specifying it is for the uncovered API surface, making its role and scope 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?

It explicitly states when to use this tool: for Google Workspace REST APIs not covered by a dedicated tool. It also communicates important constraints like allowlisted hosts and the confirm=true requirement for destructive methods, though it does not name specific alternative tools or provide explicit when-not-to-use examples.

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