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

With no annotations, the description fully carries the burden of behavioral disclosure. It explicitly notes partial success with per-row results and succeededCount/failedCount, and a hard limit of 2000 rows per call. These are critical behaviors beyond basic mutation semantics.

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 concise and well-structured: purpose, row format, then behavioral notes (partial success, limit). Every sentence adds value and there is no redundant fluff.

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 no annotations and an output schema (not shown), the description adequately covers the input format, behavioral edge cases, and limit. Minor omissions like error handling for invalid sheet_id are acceptable given the tool's 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 input schema provides zero parameter descriptions. The description compensates for the 'rows' parameter by explaining the dict structure keyed by column ID and providing an example. 'sheet_id' is not described but is self-explanatory from its name and the sheet 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 clearly states 'Add rows to a sheet', a specific verb and resource, and provides an example of the expected input format. This distinguishes the tool from siblings like update_rows and delete_row by focusing on creation.

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 provides useful constraints (maximum 2000 rows, partial success behavior) but does not explicitly mention when to use this tool versus alternatives such as update_rows or delete_row. The primary usage is implied by the tool's name and purpose, but no exclusions or comparative guidance 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the destructive and irreversible nature, the cascade delete behavior, the confirm requirement, and the subtlety that hidden descendants may exist. This is thorough and goes beyond what typical mutation descriptions offer.

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, each earning its place: the first states the core action, the second provides the critical warning and prerequisite. It is concise, well-structured, and front-loaded with 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?

The description fully covers the destructive scope, prerequisite reading, and the confirm requirement. It doesn't describe error handling or return values, but the presence of an output schema reduces that burden, and the core behavior is thoroughly explained for a tool of 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 0%, so the description must compensate. It clarifies the confirm parameter's requirement and purpose, but does not explicitly explain sheet_id or row_id. However, their names strongly imply their roles (sheet and row identifiers), providing partial compensation for the schema 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 states the tool deletes a row and all its child rows, using the specific verb 'delete' and clearly naming the resource. The all-caps emphasis on child rows distinguishes it from a simple row deletion and from sibling tools like update_row.

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 warns that the operation is destructive and not undoable, requires confirm=True, and advises reading the row and children first. It doesn't name an alternative tool, but few alternatives exist for a delete operation; the preconditions and safety guidance provide strong usage context.

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

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

The description is straightforward, implying a read-only operation via the verb 'Get' and clearly stating what is returned. However, with no annotations, it does not explicitly confirm safety, permissions, or side effects, which would be helpful for full 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 that is entirely on-topic and contains no filler. It efficiently conveys the tool's 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?

Given the simple single-parameter interface and the presence of an output schema, the description covers the essentials. It could additionally point to related tools (e.g., 'use run_report to execute') or clarify the distinction from list_reports, but this is not strictly required.

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 includes report_id (integer) with no description. The description implicitly ties report_id to the report's definition, adding a little context, but it does not explain constraints, format, or defaults. Since there is only one self-explanatory parameter, the gap is minimal.

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 a specific verb ('Get') and resource ('report's definition') with details about what the definition includes (source sheets, columns, filters). This distinguishes it from sibling tools like run_report or list_reports.

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 you need a report's structural definition) but provides no explicit exclusions or references to alternatives such as run_report or list_reports. The usage is inferable but not directly guided.

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 of disclosure. It does reveal key behavior: returns columns and rows, and is a snapshot. However, it does not explain row_limit behavior, error cases, or authentication needs, leaving some gaps.

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 key point, and every sentence adds value. 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?

Given the existence of an output schema and the tool's simplicity, the description covers the essential purpose, return contents, and usage hint. The only notable omission is explicit row_limit semantics, but the overall context is sufficient for an agent to use 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 description coverage is 0%, and the description only hints at row_limit via 'first page' and sheet_id via 'to learn the column IDs'. It does not explicitly define either parameter's meaning or how row_limit affects the result, so it fails to compensate 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?

The description clearly states the tool retrieves a sheet with columns and the first page of rows, which distinguishes it from siblings like list_sheets, list_columns, and list_rows. The phrase 'one call for a usable snapshot' reinforces the combined functionality.

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?

Explicit guidance is provided: 'Use this before writing, to learn the column IDs.' This tells the agent when to invoke the tool, but it does not explicitly mention when not to use alternatives or name them, so it falls short of a full 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?

With no annotations provided, the description carries the full safety burden. It discloses that column IDs are used as string keys and that they are prerequisite for writes, which adds behavioral context beyond a simple 'list' phrasing, though it doesn't explicitly state the operation is non-mutating.

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 filler; the first sentence states the action, the second explains the value. Well-structured and front-loaded.

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 read operation with an output schema, the description covers the essential guidance: what it does and why it's needed before writes. It doesn't complicate matters with edge cases, which are not critical here.

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 provides only the parameter name and type (sheet_id integer) with no description (0% coverage). The description indirectly refers to it as 'a sheet' but does not explain the parameter's meaning or constraints. Given the single obvious parameter, the lack is a minor 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 ('List') and resource ('a sheet's columns'), clearly differentiating it from sibling tools like list_sheets and list_rows. It also provides a rationale that ties into subsequent write operations, reinforcing its distinct purpose.

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 states these column IDs are needed 'before any write', giving clear guidance on when to use this tool. It doesn't explicitly name alternatives, but for a list operation the use case is well-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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions permission-scoped visibility ('API key can see') but does not explain pagination behavior (limit/cursor), default limits, or any other side effects. The read-only nature is implied but not explicitly confirmed.

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 that is direct and to the point. It avoids unnecessary words or repetition. However, it might be too sparse, sacrificing explanatory value for brevity, but it earns its place as a concise purpose statement.

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?

This is a simple list tool with an output schema, so the return shape is covered externally. However, the description is missing pagination details and any context about the limit/cursor parameters. While not critical for a basic list operation, the lack of such guidance makes it only minimally 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?

The input schema has 0% description coverage, and the description does not mention the limit or cursor parameters at all. These parameters are not self-explanatory beyond their names; no explanation is given for how they control result size or pagination. The description fails to compensate 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?

The description 'List reports the API key can see' clearly states a specific action (List) on a specific resource (reports) with an added scope qualifier (the API key can see). This distinguishes it from siblings like get_report (retrieves a single report) and run_report (executes/refreshes a report).

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 no guidance on when to use this tool versus alternatives. It does not mention that get_report should be used for a specific report, nor does it discuss when to pass limit or cursor. Usage is only implied by the tool's name, not explicitly explained.

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?

Discloses behavioral traits: cursor pagination by row id, max limit 500, and presence of a version field. With no annotations provided, this description carries the full burden effectively, though error handling and auth are not mentioned.

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 concise sentences, front-loaded with the main purpose. The version note is essential for update workflows and 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?

With an output schema present, the description doesn't need to explain return values. It covers the key operational details (pagination, limit, version) adequately for a simple list 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 has 0% description coverage. The description hints at limit ('Max limit 500') and cursor ('cursor-paginated'), and sheet_id via 'sheet's rows', but does not explicitly define each parameter or how cursor is used in practice.

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?

Clearly states 'List a sheet's rows' with specific pagination detail, distinguishing it from siblings like list_sheets and list_columns which target different resources.

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?

Provides context for when to use (listing rows) with cursor-pagination and max limit, and the version note suggests use before updates. However, no explicit exclusions or alternative tool mentions, though the resource-specific wording makes it evident.

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 provided, the description carries the full burden. It discloses important behavioral traits: cursor-based pagination, the need to pass nextCursor, the maximum limit of 500, and the scope restriction to sheets the API key can see. This goes beyond a simple listing to inform the agent of operational details, though it does not cover error cases or ordering.

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, front-loaded with the purpose, and every part provides value. No filler or repetition.

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's simplicity and the presence of an output schema, the description covers the key aspects: scope, pagination, and limits. It does not address every potential detail (like sorting or errors), but for a list tool with an output schema, this is adequate.

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 provides property names, types, and defaults but no descriptions. The description adds meaning by explaining how to use cursor (pass the returned nextCursor) and constraining limit (max 500). This compensates for the 0% schema description 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 clearly states the tool's function with a specific verb and resource: 'List sheets the API key can see.' It distinguishes from sibling tools like get_sheet or list_rows by focusing on the sheet collection. The pagination note adds context, making the purpose 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 when to use this tool (when listing sheets) but does not explicitly compare it to alternatives like get_sheet or mention when not to use it. It provides clear context for its function, but no exclusions 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that results are cursor-paginated and the maximum limit is 500, which is helpful. However, it does not state whether running a report has side effects, requires any special permissions, or how errors are handled.

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 primary purpose and then provides key pagination details. No unnecessary words or repetitions.

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 presence of an output schema, return values are already documented. The description covers the core purpose, pagination behavior, and limit cap, which are sufficient for invoking the tool. It could mention usage relative to sibling tools or error conditions, but for a simple 3-parameter tool, it is reasonably complete.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for 'limit' (max 500) and 'cursor' (pagination token), but 'report_id' is not explicitly described. The name is fairly obvious, and the description partially covers the parameters, but not fully.

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: 'Run a report and return its rows.' It uses a strong verb ('run') and specifies the resource ('report') and output ('rows'). This distinguishes it from sibling tools like get_report (likely metadata) and list_reports (listing reports).

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 have a report_id and want to retrieve data rows, but it does not explicitly mention when to use this tool over alternatives or provide exclusions. It lacks a direct reference to sibling tools like get_report for metadata-only needs.

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 provided, the description fully carries the burden of disclosure. It reveals critical behaviors: partial update semantics ('cells carries ONLY the changed cells'), optimistic concurrency checking via `version`, and the conflict response ('version_conflict rather than a silent overwrite'). This is exemplary 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 compact and front-loaded with the primary action. The second sentence about cells is essential and the paragraph about version/conflict is valuable guidance. Every sentence earns its place without fluff or repetition.

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 having no annotations, the description covers the key aspects needed to use the tool safely: single-row scope, partial update, conflict detection, and follow-up action. An output schema exists, so return values don't need elaboration. The tool is well-described for its 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 0%, so the description must compensate. It adds meaning to the two non-trivial parameters: `cells` (only changed cells, not the whole row) and `version` (current row version used for optimistic concurrency). `sheet_id` and `row_id` are left to be inferred from names/context, which is acceptable. Given the partial compensation, a score of 4 is warranted.

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

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

The description opens with a specific verb and resource: 'Update one row's cells.' It clearly states the scope (one row) and distinguishes from the sibling tool 'update_rows' (bulk update) and 'delete_row'. This is a precise, non-tautological purpose.

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 provides clear behavioral guidance: how to use the `version` parameter and what to do when a version conflict occurs ('read the row again and decide whether your change still applies'). It doesn't explicitly name alternatives or exclusion criteria, but the single-row scope is clear and the conflict-handling instructions are actionable.

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 provided, the description carries the full burden and excels: it reveals the critical overwrite-not-merge behavior, per-row version checking, partial success semantics, and a hard limit of 2000 rows. This goes well beyond basic read/write hints.

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

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

The description is compact, front-loaded with the primary action, and uses a clear NOTE block for critical behavioral differences. Every sentence contributes essential information with zero fluff.

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's complexity (batch mutation, versioning, partial success, size limits) and lack of annotations, the description covers all major operational aspects. The presence of an output schema means return values need not be explained, and the description is sufficiently complete for an agent to use 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 0%, so the description must explain parameters. It does specify that each row item needs 'id', 'version', and 'cells', and clarifies that 'cells' overwrites the entire cell set. However, it doesn't detail types for 'id'/'version' or provide an example, leaving some ambiguity.

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 'Update many rows' with a specific verb and resource, and immediately distinguishes itself from the sibling update_row by contrasting bulk behavior. This makes the tool's scope 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?

The description explicitly notes the difference from update_row ('unlike update_row, bulk cells OVERWRITES... rather than merging'), providing an implicit when-to-use vs alternative. It also gives concrete constraints: requires id/version/cells per item, partial success with individual version checks, and a 2000-row maximum.

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 provided, the description carries the burden of behavioral disclosure. It clearly communicates the tool's diagnostic nature and how it differsiates between key and scope issues. It does not explicitly state side-effect safety, but the read-only implication of 'whoami' is strong, and the output schema covers return details.

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: the first states the tool's purpose, and the second adds actionable usage guidance. It is front-loaded, concise, and contains no superfluous 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?

The tool is simple with no parameters and an output schema, so the description does not need to explain return values. It provides purpose and clear usage guidance, and the sibling context confirms the tool's unique role. The description is complete for effective tool selection and 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 tool accepts zero parameters, and the input schema is empty with 100% coverage. The description properly omits parameter details since there are none. This matches the baseline for zero-parameter tools.

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 the tool as an API-key introspection endpoint, stating that it reveals the key owner, scopes, and rate limit. This is a specific verb+resource description that distinguishes it from sibling tools, which all operate on sheets and reports.

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 provides explicit when-to-use guidance: 'Call this first if anything is failing — it distinguishes a bad key from a scope problem.' It does not explicitly name alternatives, but the sibling list shows no overlapping tool, making the guidance clear enough for an agent to select it in troubleshooting scenarios.

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