gdrive_create_doc

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.