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

No annotations are provided, so the description carries full behavioral burden. It discloses that the operation duplicates rather than moves the original, supports optional renaming/re-parenting, and that dry_run=True previews without committing. It stops short of mentioning permission requirements or name-collision behavior, but the core side-effect profile is clear.

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

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

The description is compact and well-organized: purpose first, then discovery prerequisite, use/not-for guidance, dry-run note, and an args list. Every section adds value and there is minimal redundancy with the schema.

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 six parameters, no annotations, and zero schema coverage, the description covers the operation, workflow prerequisites, sibling alternative, dry-run behavior, and all argument meanings. Minor gaps around how name-based and ID-based references are resolved remain, but an output schema exists so return-value details need not be repeated.

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 compensates by explaining each of the six arguments in plain language, including the useful note that file_id is 'preferred when known'. It does not fully specify precedence between file_name/file_id or destination_folder/destination_folder_id, but the provided semantics are sufficient for basic invocation.

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?

Opens with 'Copy a Google Drive file, optionally renaming and/or placing under a new folder' — a specific verb and resource. It further clarifies the purpose as 'duplicating a file/template' and explicitly contrasts with gdrive_move, making sibling differentiation clear.

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

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

Provides explicit guidance: 'Use this for: duplicating a file/template. Not for: moving the original file — see gdrive_move.' It also instructs the agent to run gdrive_search or gdrive_list_folder first to obtain required identifiers, so the when and how are both covered.

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 the optional dry_run behavior for previewing changes, and implies a mutation without stating irreversibility. It could mention what happens on success (e.g., returns ID) but given the output schema exists, lacking that is acceptable. The dry_run disclosure is valuable and clear.

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

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

The description is well-structured with clear sections and short sentences that front-load core info and exclusions. The bullet-style 'Not for' list is efficient, and the Args section is concise. No wasted words; every sentence contributes to usage understanding.

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 moderate complexity and the existence of an output schema, the description covers key aspects: core action, exclusions, discovery step, dry_run flag, and parameters. It doesn't elaborate on return values or edge cases, but those are less critical with the output schema present. The only gap is a deeper note on permission requirements or side effects, but that's minor.

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

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

Schema description coverage is 0%, so the description must compensate. It lists each parameter's purpose in the Args section (title, content, parent_folder, parent_folder_id, dry_run) but adds minimal extra detail—such as the default behavior for parent_folder. It doesn't clarify the distinction between name and ID or how to obtain them beyond the discovery hint, but it does cover the basic semantics.

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

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

The description clearly states the tool creates a Google Doc in Drive with optional seeded content, and explicitly distinguishes it from folder creation, plain file writes, and spreadsheets. This precise verb-resource pairing plus sibling differentiation makes the purpose 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?

It explicitly says when to use (creating a Google Doc artifact) and when not to, naming the alternative tools for each excluded case (gdrive_create_folder, gdrive_write_file, gsheets-mcp). It also provides a discovery step hint to find parent folder IDs, which is actionable 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 behavioral burden. It discloses the meaning of dry_run ('preview the change without committing') and exist_ok ('return an existing same-named child folder instead of erroring'), plus the default parent behavior of 'My Drive root.' It does not mention permissions or auth requirements, but for a non-destructive create with an output schema, the key behavioral traits are covered.

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 organized with clear sections: a one-sentence purpose, a Discovery note, Use/Not-for bullets, and an Args list. Every sentence earns its place, and the most important usage distinctions are front-loaded before the parameter details.

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

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

For a 5-parameter creation tool with an output schema and no annotations, the description is complete. It covers alternatives, discovery steps, default behavior, safety flags, and parameter semantics, giving an agent everything needed to invoke the tool correctly without consulting additional context.

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 fully compensate. It explains each parameter: folder_name, parent_folder with default, parent_folder_id as stable ID, exist_ok, and dry_run. This goes well beyond the bare schema field names and gives an agent enough to choose and fill parameters correctly.

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

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

The description states a specific verb and resource: 'Create a folder in Google Drive.' It further differentiates itself from siblings with explicit 'Not for' clauses covering gdrive_create_doc, gdrive_rename, and gdrive_move, so an agent can immediately tell this tool apart from related 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?

The description explicitly says when to use the tool ('Use this for: creating a new folder') and when not to use it, naming the alternative tools. It also gives discovery guidance to run gdrive_search or gdrive_list_folder first when nesting under an existing folder, leaving minimal ambiguity about invocation context.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses that Google Docs/Sheets/Slides are exported to Office formats while other files download in native binary form, and that dry_run previews without writing bytes. It does not mention overwrite behavior or directory creation, but the core side effects are clearly stated.

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 purpose is front-loaded, followed by format behavior, discovery instructions, explicit use/not-for routing, and a terse Args list. Every sentence earns its place, and the structure is easy to scan.

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

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

Given no annotations and a schema with zero parameter descriptions, the description covers purpose, alternatives, discovery, conversion behavior, and every parameter. Minor omissions like overwrite semantics and file_name/file_id precedence keep it from being fully complete.

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

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

The input schema has no parameter descriptions, so the Args block adds meaningful value: local_path is a destination path or directory, file_id is an optional stable ID preferred when known, and dry_run previews without writing. It could further explain how file_name and file_id interact when both are supplied.

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 and resource: 'Download a Google Drive file to a local filesystem path.' It also distinguishes itself from the sibling gdrive_read_file by framing this tool as saving for offline/binary use rather than reading text content in-chat.

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 says 'Use this for: saving a Drive file locally for offline/binary use' and 'Not for: reading text content in-chat — see gdrive_read_file.' It also directs agents to gdrive_search or gdrive_list_folder first to obtain file_name/file_id, which is clear usage guidance.

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

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

With no annotations, the description carries the transparency burden. It clarifies that folder_id is optional and preferred, that folder_name can be a human-readable name, and that this tool is not the recursive listing variant. It stops short of describing edge-case behavior like when neither argument is supplied, but the core behavioral intent is clear.

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 tightly organized into labeled sections: main purpose, args, discovery workflow, and sibling alternatives. Every sentence contributes useful information and no filler is present.

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

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

Given the simple two-parameter schema and the presence of an output schema, the description is nearly complete. It covers lookup methods, the recommended discovery flow, and differentiation from siblings. The only notable gap is that both parameters are optional in the schema, and the description does not explicitly state what happens if neither is provided.

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 supply meaning for the parameters. It explains folder_name as a listing key with an example, and folder_id as an optional stable ID originating from gdrive_search. This adds value beyond the bare schema property titles, though it could more explicitly state precedence when both are provided.

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 ('List files in a Google Drive folder') with two clearly named lookup modes (folder_name or folder_id). It also distinguishes itself from nearby sibling tools by naming gdrive_list_folder_recursive as the subfolder-inclusive alternative.

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 explicit workflow guidance: use gdrive_search first when the exact folder is unknown. It also names sibling tools and their specific use cases, so an agent knows when to use this tool versus gdrive_list_folder_recursive or gdrive_read_file.

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 behavioral burden, and it does state the key behavioral trait: recursive traversal through subfolders. It also clarifies the preference for a stable folder_id from search. It stops short of describing error behavior or what happens if neither argument is supplied, but for a read-only listing tool the core behavior is sufficiently disclosed.

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 purpose, and organized into short labeled sections for args, discovery, and sibling tools. Every line adds information needed to select or invoke the tool correctly.

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 output schema, return values are covered elsewhere, and the description covers argument semantics and alternative tools well. The main remaining gap is that it does not explicitly state whether at least one of folder_name or folder_id is required, despite both being optional in the schema.

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

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

Schema description coverage is 0%, and the schema only provides titles and null defaults. The description compensates fully by explaining folder_name with a concrete example, labeling folder_id as optional and preferred when known, and pointing to gdrive_search as the discovery mechanism.

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: 'Recursively list all files in a Google Drive folder and its subfolders.' It explicitly distinguishes itself from gdrive_list_folder for shallow listing, so an agent can immediately tell which tool to use.

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 gives clear routing guidance: use gdrive_search first when the folder identifier is unknown, use gdrive_list_folder for shallow listing, and use gdrive_read_file to read a discovered file. This leaves no ambiguity about when to choose this tool over its siblings.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the scope ('visible to the authenticated account') but does not state anything about max_results behavior, pagination, output format, or side effects (though 'List' implies read-only). This leaves significant behavioral gaps for an agent to understand the tool's full behavior.

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

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

The description is two sentences with no filler. The first sentence front-loads the core purpose, and the second provides actionable sibling guidance. Every word contributes to agent understanding, making it appropriately 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 list tool with an output schema present, the description is mostly adequate: it states what is listed and how to proceed into shared drives. However, it omits any explanation of max_results or pagination/limit behavior, which is a notable gap for correct invocation. The sibling guidance helps, but the missing parameter semantics keep it from being fully complete.

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

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

The input schema has only one parameter (max_results) with 0% schema description coverage. The description does not mention this parameter at all, failing to explain what max_results controls, its default behavior, or how it affects results. No semantic value is added beyond the schema's bare title.

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 resource ('Shared Drives') with a clear scope ('visible to the authenticated Google account'). It differentiates from siblings by indicating that folder-level operations happen via gdrive_search/gdrive_list_folder with folder_id values discovered inside a Shared Drive, making the tool's 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 second sentence explicitly names sibling tools as the next step after listing shared drives, providing a clear workflow context. It does not explicitly state when not to use this tool, but the alternative path (use gdrive_search/gdrive_list_folder inside a Shared Drive) is implied, giving adequate usage guidance without exhaustive 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?

With no annotations, the description carries the behavioral burden. It usefully discloses the dry_run preview behavior and notes that file_id is preferred when known, but it doesn't cover mutation consequences, error behavior, or what happens when multiple identifiers/folders are supplied.

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; every sentence earns its place, and the Args list is not mere schema duplication because it adds semantic meaning not present in the schema.

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

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

For a 5-parameter, no-annotation mutation tool, it covers discovery, use vs non-use, dry-run, and argument semantics. With an output schema present, not explaining return values is acceptable, though precedence among identifiers could make it fully complete.

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

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

Schema coverage is 0%, so the description must explain the parameters, and it does: all five args get one-line semantic explanations, including the useful guidance that file_id is preferred when known. It stops short of stating precedence rules if both name and ID are passed.

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?

Opens with a specific verb and resource: 'Move a file to a different folder in Google Drive.' It is immediately distinguishable from rename/copy siblings, and the 'Use this for / Not for' lines reinforce the precise scope.

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?

Explicitly instructs when to use it (moving files between folders), when not to (renaming in place), and points to gdrive_rename as the alternative. It also prescribes a discovery step (gdrive_list_folder/gdrive_search) before calling.

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 must fully disclose behavior. It does mention format support and export behavior (e.g., Google Docs exported as plain text, Sheets as CSV), which is useful. However, it does not disclose potential edge cases like file size limits, truncation behavior beyond max_chars, authentication requirements, or error handling when a file is not found. These gaps mean the description carries only partial 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 structured with bullet points for supported formats and a clear 'Args' section, making it easy to scan. It front-loads the purpose and then provides details. It is slightly longer than necessary but every section adds value; there is no fluff. The organization is logical and efficient, though not as terse as a two-sentence example.

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

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

Given that an output schema exists, the description does not need to explain return values. It covers the tool's core function, supported file types, parameters, and discovery workflow. It could be improved by mentioning failure modes or limitations (e.g., what happens if the file is too large), but overall it is sufficiently complete for an agent to call the tool correctly in most scenarios.

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?

Since the schema has 0% description coverage, the description must compensate. It does so thoroughly in the 'Args' section: it explains file_name with an example, max_chars with a default, and file_id as an optional stable ID with a preference note. It also clarifies the relationship between file_name and file_id. This adds significant meaning beyond the bare schema and fully addresses all 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 clearly states the action: 'Read the contents of a file from Google Drive' and lists supported formats (Google Docs, Sheets, PDFs, text files). This is a specific verb+resource, and it distinguishes itself from sibling tools like onedrive_read_file by specifying the Google Drive context. It also names related discovery tools, further clarifying its role.

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 advises using discovery tools (gdrive_search, gdrive_list_folder, or gdrive_list_folder_recursive) first to locate the file, and it notes that file_id is 'preferred when known'. This gives clear context on when to use the tool, though it does not explicitly state when not to use it or alternative tools beyond discovery. Still, the guidance is practical and 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the dry_run behavior ('Preview the rename without committing it'), which is a meaningful behavioral trait. It also implies that file_id is preferred when known, which is useful operational context. However, it doesn't mention whether the rename is reversible, whether it requires specific permissions, or what happens if both file_name and file_id are provided. Still, the dry_run disclosure and the file_id preference add real value beyond the schema.

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

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

The description is compact and well-structured. It front-loads the core purpose, then provides discovery guidance, usage boundaries, a dry_run note, and parameter explanations. Every sentence earns its place, and the structure makes it easy for an agent to scan. The 'Use this for' / 'Not for' pattern is particularly effective.

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

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

The tool has 4 parameters, no annotations, and no schema description coverage, so the description must be thorough. It covers the core purpose, discovery prerequisites, the alternative tool, the dry_run behavior, and all parameters. The output schema exists, so return values don't need to be explained. The only minor gap is the lack of explicit precedence rules when both file_name and file_id are provided, and no mention of error conditions (e.g., file not found). Overall, it is nearly complete for an agent to invoke 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 for the schema's lack of parameter documentation. The description lists all four parameters (file_name, new_name, dry_run, file_id) and adds meaning: file_name is 'Current name of the file to rename', new_name is 'New name for the file', dry_run is 'Preview the rename without committing it', and file_id is 'Optional stable file ID (preferred when known)'. This is a strong compensation for the schema's bare titles, though it could be even more explicit about the relationship between file_name and file_id (e.g., which takes precedence).

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 clear verb and resource: 'Rename a file in Google Drive.' It explicitly distinguishes itself from moving a file to a different folder and names the sibling tool gdrive_move. This makes the tool's purpose unambiguous and easily differentiated from siblings.

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 guidance: run gdrive_list_folder or gdrive_search first to obtain file_name/file_id values. It also states when to use this tool ('renaming files in place') and when not to ('moving a file to a different folder — see gdrive_move'). This is exactly the kind of when/when-not/alternatives guidance that helps an agent select the right 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?

No annotations are provided, so the description carries the full burden. It discloses the search scope (file names, Shared Drives) and default max_results, but does not mention side effects, permissions, read-only nature, pagination, or query syntax. This is minimal for an unannotated tool.

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

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

The description is short and front-loaded with the core purpose, followed by a compact args listing. No wasted words, though it could add usage guidance without bloating.

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 search tool with an output schema and both parameters documented in the description, this is minimally viable. However, it lacks guidance on when to use it vs. list tools and omits behavioral details that are not covered elsewhere.

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: query is defined as 'Search term to find in file names' and max_results as 'Maximum number of results to return (default: 20)', adding real meaning beyond the raw schema.

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

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

The description states a clear verb and resource: 'Search for files in Google Drive by name' and adds the useful scope 'includes Shared Drives.' It does not explicitly compare against sibling tools like gdrive_list_folder or onedrive_search, but it is specific enough to be distinguished from listing/browsing 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 usage by saying 'by name' but never states when to prefer this tool over alternatives such as gdrive_list_folder or gdrive_list_shared_drives. No explicit when-not guidance 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?

With no annotations provided, the description carries the full burden. It discloses the mutation risk via 'dry_run=True to preview the change without committing,' clarifies valid roles, and mentions that send_notification controls whether Google emails the collaborator. It could go further by describing permission overwrite behavior or revocation, but it gives meaningful behavioral context beyond the raw schema.

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

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

The description is well structured and front-loaded with the core purpose, followed by discovery, usage boundaries, and a tidy Args list. Every line earns its place; the only minor repetition is the role list appearing twice, but this aids clarity rather than harming it.

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

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

For a 6-parameter sharing tool with no annotations and an output schema present, the description is complete: it explains prerequisites, valid inputs, dry-run behavior, and what each parameter does. An agent has enough information to select and invoke the tool correctly without needing to open the schema.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: every one of the 6 parameters gets a plain-language meaning. It clarifies that file_id is 'preferred when known,' that role is constrained to reader/commenter/writer, and that dry_run previews without committing. This is exactly the semantic enrichment the schema lacks.

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: 'Share a Google Drive file/folder with a user email.' It is clearly distinct from sibling tools like gdrive_copy, gdrive_move, gdrive_rename, and gdrive_trash because it is about granting access permissions rather than manipulating the file itself.

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 says 'Use this for: granting reader/commenter/writer access to a collaborator. Not for: transferring ownership.' It also provides a discovery workflow: run gdrive_search or gdrive_list_folder first to get file_id/file_name. This tells an agent both when to use the tool and what it should not be used for.

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

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

No annotations exist, so the description carries the behavioral burden. It discloses that the operation is a soft delete ('recoverable from trash') and offers dry_run=True to preview. It stops short of describing permissions or edge cases, but the core mutation behavior is transparent.

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?

At roughly 90 words, it is short, front-loaded with the core action, and uses clear labeled sections for use/not-use and args. The only minor redundancy is dry_run appearing in both the prose and the arg list.

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

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

For a three-parameter mutation with no required parameters and an output schema, the description covers discovery, use cases, and dry-run behavior. It leaves minor ambiguity about identifier precedence but is otherwise complete enough for an agent to invoke 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%, and the description compensates by explaining all three parameters: file_name names the target, file_id is the 'stable file ID (preferred when known)', and dry_run 'previews the trash without committing.' It does not clarify whether file_name is required when file_id is absent, or the precedence when both are supplied.

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 opening sentence uses a specific verb and resource: 'Move a Google Drive file or folder to trash.' It also clarifies the scope by contrasting with permanent deletion, distinguishing it from any delete-like operation. The sibling list contains no competing trash tool, so it stands apart.

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

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

It explicitly scopes use cases: 'Use this for: soft-deleting... Not for: permanently deleting — not supported by this server.' It also provides a discovery prerequisite: run gdrive_search or gdrive_list_folder first to obtain file_name/file_id. This is unambiguous when-to-use guidance.

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

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

With no annotations, the description carries the behavioral burden. It discloses the operation, the token prerequisite, and the supported mutation types. However, it does not explain what 'undo' means per operation type, whether the action is destructive or reversible, or how failures or invalid tokens 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 compact and front-loaded: the core purpose appears in the first sentence, and the supported tools and token explanation follow without repetition or fluff. Every sentence 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 single-parameter tool, the description provides a workable baseline: what it does, which operations it supports, and where its input comes from. But because there is no output schema and no annotations, the agent is left without guidance on per-operation undo semantics, error behavior, idempotency, or expected return values.

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 only defines restore_token as a required string, so schema description coverage is 0%. The description compensates by stating that the token is returned by a mutating gdrive_* tool after commit, giving the agent concrete provenance and validity context. It stops short of describing token format or exact response field names, so a 4 is appropriate.

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: 'Undo a prior Drive mutation using its restore_token.' It also lists the exact sibling tools it can undo, which clearly distinguishes it from gdrive_rename, gdrive_move, gdrive_trash, and the other mutation tools in the sibling list.

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

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

The supported-tools list and the requirement that restore_token come from 'a mutating gdrive_* tool after commit' give the agent clear context for when to invoke this tool. It does not explicitly state when not to use it, but the undo scope is specific enough that alternatives are implicitly identified.

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 fully discloses side effects and edge cases: dry_run behavior, overwrite trigger conditions, undo semantics ('Undo trashes newly created files; content overwrites are not undoable via restore_token'), and default MIME guessing. This goes far beyond a basic read/write label.

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 structure is clear and front-loaded with purpose and usage, followed by Args. However, some repetition exists (e.g., dry_run and overwrite are explained both in the narrative and the Args list), so it is slightly less concise than it could be while still being highly 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?

Given 8 parameters, no annotations, and 0% schema coverage, the description is remarkably complete: it covers discovery, overwrite behavior, dry-run, undo limits, and defaults. Minor gaps remain, such as how binary content is encoded (base64 vs raw string) and precedence when both parent_folder and parent_folder_id are supplied, but these are not critical for typical 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 description carries full parameter meaning. The Args section explains every parameter with practical context: parent_folder by name vs parent_folder_id as stable ID, overwrite triggering on same-named file, and dry_run previewing the commit. It also clarifies optional MIME inference from file_name.

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, resource, and capability: 'Create or overwrite a text/binary-capable file in Google Drive.' It then explicitly excludes sibling tools ('Not for: creating a Google Doc — see gdrive_create_doc') and ('Not for: spreadsheet edits — use gsheets-mcp'), so an agent can disambiguate it without opening schemas.

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 gives clear when-to-use guidance: 'Use this for: writing markdown/text/json/csv files into Drive' and explicit not-for alternatives with sibling tool names. It also provides a discovery first-step: 'run gdrive_search or gdrive_list_folder first to obtain parent folder and optional existing file_id values.'

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 disclosing behavior. It only says 'Check if OneDrive re-authentication completed,' but does not explain what happens if not completed, whether it blocks or returns immediately, what the return value indicates, or any side effects. This is insufficient for a tool that likely returns a status or error, and the agent has no idea what to expect.

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—two short sentences—and front-loads the core purpose. Every word earns its place, and there is no redundancy. However, it is so brief that it under-specifies behavior, but that is a completeness issue, not a conciseness issue. For structure, it is appropriately sized.

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

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

The tool has an output schema (though not shown in the context), and no parameters, so the description should explain the return value or how to interpret the completion status. It does neither. It also fails to mention any potential errors, timeouts, or prerequisites beyond 'call after user visits URL.' For a tool that is part of a two-step re-authentication flow, this is incomplete; an agent needs to know what to do with the result.

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

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

There are zero parameters, and the schema has full coverage (vacuously). The description adds no parameter information, but none is needed. Per the rubric, the baseline for 0 parameters is 4, and the description does not detract from that. It correctly implies there are no inputs to configure.

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 ('Check') and a resource ('OneDrive re-authentication'), but it is vague about what 'completed' means and what the outcome looks like. It distinguishes itself from onedrive_start_reauth implicitly, but not explicitly. The purpose is clear enough to avoid tautology, but lacks specificity about the check's result.

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 instruction 'Call after user visits URL' provides a clear temporal context for when to use the tool. It does not mention alternatives or exclusions, but the sibling tool onedrive_start_reauth is the obvious counterpart, and the usage context is unambiguous. No further guidance is given, but the minimal context is adequate for a simple check 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, and the guidance about needing an exact path is useful, but it does not mention recursion behavior, failure modes, authentication requirements, or any side effects. The description is adequate but minimal.

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

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

The description is compact and well-structured: purpose first, then parameter semantics, then discovery and sibling guidance. Every sentence adds value and none are redundant.

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

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

For a simple one-parameter list tool with an output schema present, the description covers the core purpose, the parameter, and routing to sibling tools. It does not explain return contents or edge cases, but the output schema handles that. Overall it is complete enough for 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 coverage is 0% for the single parameter, so the description must compensate. It defines folder_path as a path string with concrete examples ('Documents/Projects' or 'Stock Investor Accelerator'), adding meaning beyond the bare schema. It could go further with format details but is sufficient.

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 'List items in a OneDrive folder by path,' a specific verb + resource + method. It also names sibling tools (onedrive_list_root, onedrive_read_file) to distinguish this tool's scope, so an agent can immediately tell what it does vs. alternatives.

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?

Explicitly says to use onedrive_list_root or onedrive_search first when the exact folder_path is unknown, and directs the agent to onedrive_read_file for reading discovered files. This clearly covers when to use this tool and when to prefer alternatives.

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

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

With no annotations provided, the description carries the full burden. It transparently states the core behavior of listing items in the root folder and implies non-recursive scope by directing nested-folder cases to a sibling. It does not mention pagination or permissions, but the output schema covers return structure, and the operation is simple enough that this is a minor gap.

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 short sentences, no filler. The core behavior is front-loaded, and the sibling routing is a natural second sentence. 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 zero-parameter read-only list operation with an output schema, this description is complete: it states what is listed, where, and which sibling to use for other cases. An agent has everything needed to call 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?

The tool has zero parameters)Skip; the input schema is an empty object, so there are no parameter semantics to clarify. The description sensibly omits parameter details, and the baseline for zero-parameter tools is 4.

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: 'List items in the OneDrive root folder.' It clearly signals the scope is the root folder, which distinguishes it from sibling onedrive_list_folder that handles nested folders. An agent can immediately identify the tool's purpose 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 explicitly names alternatives with conditions: 'use onedrive_list_folder for nested folders and onedrive_read_file to read a discovered file.' This tells the agent exactly when not to use this tool and which sibling to choose instead, leaving no inference required.

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 explaining behavior. It does this well by noting that PDFs have text extracted, Excel files are exported in CSV-like format, and max_chars limits the amount returned. It could also mention unsupported file types or error behavior, but it is substantially transparent for a read operation.

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

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

The description is well-organized with a short intro, a useful supported-formats list, parameter definitions, and a discovery note. Every section earns its place, and no unnecessary filler is present.

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

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

Given the tool's moderate complexity, the description covers the essential workflow: finding the file path first, supported formats, and the main parameters. An output schema exists, so return structure need not be described. It is complete enough for an agent to invoke the tool correctly, though it omits details like auth requirements and error handling.

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 fully explain the parameters. It does: file_path is defined with concrete examples, and max_chars is described as the maximum characters to return with its default. This goes beyond the bare schema, which only provides types and a default.

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: 'Read the contents of a file from OneDrive.' It clearly explains what operation is performed and distinguishes this from the sibling list/search/write tools, while also naming the supported file types.

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 instructs the agent to use onedrive_search, onedrive_list_root, or onedrive_list_folder first to discover the exact file_path. This gives clear when-to-use context and useful preconditions, though it does not enumerate exclusion cases or compare directly with the gdrive read/download siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic function and does not mention authentication requirements, case sensitivity, read-only nature, or any side effects. Significant behavioral context is missing.

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 the purpose front-loaded and the parameter details listed efficiently. It avoids unnecessary verbosity while still delivering the essential 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?

Given the tool's simplicity and the existence of an output schema, the description still lacks important contextual details such as authentication prerequisites, search behavior limitations, and any notes about performance or rate limits. It is minimal but leaves gaps for an agent to infer.

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

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

Although the schema itself has no parameter descriptions, the description adds meaningful semantics: 'query' is described as a search term for file names, and 'max_results' is described as a maximum count with a default. This compensates for the schema's lack of detail.

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 (search), the resource (files in OneDrive), and the scope (by name). It distinguishes from sibling listing tools like onedrive_list_root and onedrive_list_folder, 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 provides no guidance on when to use this tool versus alternatives such as listing tools or the gdrive_search sibling. There is no mention of when search is appropriate or any 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 are absent, so the description carries the full burden of behavioral disclosure. It mentions the output (URL and code) but does not disclose side effects such as invalidating existing tokens, requiring user interaction, or whether calling it repeatedly is safe.

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 short sentences, front-loaded with the core action and immediately clarifying the return value. There is no redundant or filler content.

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

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

For a zero-parameter tool with an output schema, this is minimally adequate: it states the action and return value. However, it lacks the relationship to onedrive_complete_reauth and any side-effect disclosure, leaving the full calling context incomplete.

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 and schema description coverage is 100%, so no parameter documentation is needed. The description nevertheless adds useful context about what the returned URL and code are 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 states a specific action, 'Start OneDrive re-authentication', on a clear resource, and adds what the tool returns ('URL and code for user'). This distinguishes it from siblings such as onedrive_complete_reauth, onedrive_list_root, and onedrive_read_file.

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. The sibling onedrive_complete_reauth implies a pairing, but the description never says that this is the first step of a two-step flow or when reauth is needed.

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