Google Sheets Agent by Nova (CIVAI)

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the iterative/recursive nature, which signals long-running, potentially expensive execution and explains the duration and query caps in the schema, but it says nothing about permissions, the connection_id requirement, cost, or failure modes.

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

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

A single well-formed sentence that front-loads the core purpose and then explains the mechanism. Nothing is padded or 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?

The tool is complex (7 parameters, no output schema, no annotations) and the description leaves the return value entirely unspecified even though no output schema exists to cover it. The agent knows what the tool does procedurally but not what it yields or how results are shaped.

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

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

Schema description coverage is 100%, and each parameter (depth, breadth, max_total_queries, max_duration_seconds, connection_id) is documented with ranges and defaults in the schema. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description gives a specific verb (conduct) and resource (deep, iterative research) and even explains the mechanism: generating multiple queries, processing results, and recursing. It is clearly a research-execution tool, but it never contrasts itself with the sibling research__generate-research-report, so an agent must infer the boundary.

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

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

No when-to-use guidance, no prerequisites, and no mention of the natural alternative, research__generate-research-report (report vs. raw research). The agent gets a description of the mechanism but no instruction on when this tool is the right choice.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not say whether the generated report is persisted or merely returned, what format/length to expect, or whether it requires prior research artifacts — for a generative tool with zero annotation coverage this is a real 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?

A single front-loaded sentence with no waste; 'comprehensive' is mildly decorative but the purpose is stated immediately.

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

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

A simple two-parameter tool with fully documented params and no output schema, but the description never states what the tool returns or where the report goes, which is exactly the information missing when no output schema exists.

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

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

Schema description coverage is 100%, so both parameters (objective, research_data) are already documented in the schema. The description adds no format, size, or structuring guidance beyond that baseline, so a 3 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?

States a specific verb (generate) and resource (research report) plus the input source (existing research data), so the agent knows this synthesizes rather than performs research. It does not explicitly distinguish itself from the sibling research__conduct-deep-research, which an agent might reasonably confuse it with.

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

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

There is no when-to-use guidance, no prerequisite statement (e.g. that research must already exist), and no mention of the alternative research__conduct-deep-research for gathering new data. The agent must infer the routing decision entirely.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no statement of side effects, no indication of whether it is read-only or stateful, and no hint about what the reply contains. Only the ambiguous "reply conversationally" phrasing conveys 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?

A single sentence that front-loads the action and then the trigger condition. There is no filler, repetition, or redundancy; every clause 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?

Complexity is low (one optional param, no nested objects, no output schema), so little is required, but for a conversational fallback the agent still lacks any indication of return format or whether conversation state is involved. Adequate but with an evident gap.

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

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

There is a single optional parameter (reply_hint) with 100% schema description coverage, so the schema already documents it. The description adds no syntax, format, or content guidance for the hint beyond what the schema states, which matches the baseline 3 for high-coverage schemas.

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 ("Reply conversationally") plus the trigger condition for it. It is functionally distinguishable from the sibling CRUD tools (create/delete/get/update sheet) and the research tools, though it names no concrete resource or output artifact, keeping it short of a 5.

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

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

It gives an explicit when-to-use rule: "when the request is ambiguous or needs clarification." That is a clear selection condition against the concrete sheet/research siblings. It does not name an alternative tool or state when NOT to use it, so it falls short of 5.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing. 'Create sheet' implies a mutation, but there is no mention of permissions required, whether an existing sheet is overwritten, what the returned identifier is, or any side effects. The generic 'Run Google sheets action' phrasing adds no behavioral signal.

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

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

One short sentence with no wasted words, but the brevity comes from boilerplate rather than precision. The 'Run Google sheets action:' prefix is padding that could be replaced with substantive content at the same length.

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

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

For a mutation tool with no annotations, no output schema, and a single opaque 'detail' parameter, the description is far too thin. An agent cannot tell what the tool actually creates or how to supply meaningful detail, leaving the definition inadequate 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 description coverage is 100% for the single 'detail' parameter, so the schema already documents it, establishing a baseline of 3. The description adds nothing about how 'detail' maps to sheet creation (naming, tab structure, etc.), but it is not required to when coverage is complete.

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 restates the tool name almost verbatim ('create_sheet' → 'create sheet'), wrapped in a generic 'Run Google sheets action' boilerplate. It does not describe what the created sheet contains, where it is created, or how it differs from siblings like sheets__generate_sheet or sheets__update_sheet. This is close to a tautology.

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

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

There is no statement of when to use this tool versus the numerous siblings (generate_sheet, update_sheet, delete_sheet, converse). No prerequisites, no exclusions, no alternative routing. The agent must infer usage entirely from the tool name.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure for a destructive operation. It does not state that deletion is irreversible, whether it requires permissions, or what happens to sheet data or references — it only repeats the word 'delete'.

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 short sentence with no waste, but the boilerplate 'Run Google sheets action:' prefix consumes most of it without conveying information. It is concise but front-loads filler rather than substance.

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

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

For a destructive tool with no annotations, no output schema, and zero required parameters, the description is inadequate. It omits irreversibility, side effects, and expected outcomes that an agent would need before invoking a delete.

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 is a single parameter ('detail') with 100% schema description coverage, so the schema already documents it. The description adds no meaning beyond the schema, but per the high-coverage baseline a 3 is appropriate rather than penalizing further.

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 'Run Google sheets action: delete sheet' is essentially a restatement of the tool name sheets__delete_sheet, which is the definition of a tautology. It states a verb and resource but adds no distinguishing detail versus siblings like update_sheet or create_sheet.

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

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

There is no guidance on when to use this tool versus alternatives such as update_sheet, get_sheet, or create_sheet. The only context is a boilerplate prefix ('Run Google sheets action'), which gives the agent nothing to route on.

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, and it discloses nothing: not whether a sheet is created, overwritten, or derived; not auth requirements; not the effect on an existing spreadsheet. It is effectively opaque beyond the name.

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

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

One short sentence, but its brevity comes from under-specification rather than efficiency. "Run Google sheets action:" is filler that consumes the whole description without conveying information.

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

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

For a mutation-style generate action with no annotations, no output schema, and no explanation of what "generate" produces, the description is far too thin. An agent cannot confidently call it or predict 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?

Single parameter with 100% schema description coverage, so the schema already documents "detail" as task-specific objective details. Per the baseline for high coverage, a 3 is appropriate; the description adds no meaning beyond it.

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

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

"Run Google sheets action: generate sheet" restates the tool name in wrapper phrasing without adding specificity. It does not distinguish generate_sheet from sibling create_sheet, converse, or update_sheet, all of which operate on the same resource.

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

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

No guidance on when to use this tool versus create_sheet or the other sheets siblings. The agent is left to infer that "generate" differs from "create" purely from the name, which is not 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?

No annotations are provided, so the description carries the entire behavioral burden, and it discloses nothing: no read-only vs. mutating status, no auth/permission requirements, no indication of what is returned or how a sheet is identified. The boilerplate phrase 'Run Google sheets action' adds zero behavioral content.

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

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

It is very short and front-loaded, but the 'Run Google sheets action:' prefix is pure template padding that earns no place, and the remainder is under-specified rather than concise. There is no useful structure or content to organize.

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

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

With no annotations and no output schema, the description must explain operation semantics, but it supplies nothing — not what a 'get sheet' returns, not how the target sheet is determined, not any prerequisite. For even this simple one-parameter read tool, the definition is materially 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?

There is a single parameter ('detail') and schema description coverage is 100%, so the schema already documents it. The description adds no meaning beyond the schema, which is the expected baseline 3 when the schema does the heavy lifting.

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 reads 'Run Google sheets action: get sheet,' which is effectively the tool name restated with template boilerplate around it. It gestures at a verb (get) and resource (sheet) but conveys no scope, return content, or distinction from siblings like sheets__list_sheets or sheets__generate_sheet.

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

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

No when-to-use guidance is present at all, and no alternative tools are referenced. An agent cannot tell from this text whether it should call get_sheet, list_sheets, or generate_sheet for a given request.

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' weakly implies a read-only operation, but the description never states that, nor does it describe scope (all sheets? within a file?), pagination, or return shape.

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

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

A single short sentence with no redundancy, so it is not verbose, but the brevity comes at the cost of under-specification rather than economy of expression.

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

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

With no output schema and no annotations, the description must explain what a caller gets back; it says nothing about the return payload or how results are scoped. For a list tool in a family of similar sheet operations, this is an incomplete definition.

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 is a single optional parameter 'detail', fully described in the schema as 'Task-specific details from the objective.' Schema coverage is 100%, so the baseline of 3 applies; the description adds no additional meaning about how detail influences the listing.

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

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

The description names a verb ('list') and resource ('sheets'), so the intent is inferable, but it is wrapped in a generic 'Run Google sheets action:' template that adds nothing. It does not distinguish this from the sibling get_sheet, which an agent could easily confuse for the same read operation.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as get_sheet or generate_sheet. The agent is left to guess whether 'list' means enumerate sheet names, enumerate tabs within a spreadsheet, or something else.

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. The verb 'update' at least implies a mutation, but the description says nothing about required permissions, what fields can change, reversibility, or side effects on existing sheet content.

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

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

It is a single short sentence with no wasted words, but it is under-specified rather than concise — the brevity comes from omitting information rather than from efficient phrasing.

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

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

For a mutation tool with no annotations and no output schema, the description should disclose at least what is being modified and any prerequisite context. Instead it offers only a generic action wrapper over a single vaguely named 'detail' parameter.

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 is a single parameter whose schema description coverage is 100% ('Task-specific details from the objective'), so the schema already documents it. The description adds no additional meaning about what 'detail' should contain, which matches the baseline 3 for high schema 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 pairs the verb 'update' with the resource 'sheet', which is enough to separate it from create/delete/get/generate siblings by inference. However, the phrasing 'Run Google sheets action: update sheet' is a generic wrapper that restates the tool name rather than stating what is actually updated, so the purpose is only vaguely specified.

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

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

There is no guidance on when to use this tool versus the many siblings (create_sheet, delete_sheet, get_sheet, generate_sheet, converse). No preconditions, alternatives, or exclusions are mentioned.

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