Google Workspace MCP VE

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.19.0
Disambiguation5/5
Each tool has a clearly distinct purpose, with detailed descriptions that cross-reference other tools to guide correct selection. Overlapping tools (e.g., modify_doc_text vs. insert_doc_markdown) are differentiated by use case and behavior, minimizing ambiguity.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., create_doc, list_spaces, manage_event). A few outliers like debug_docs_runtime_info and start_google_auth break the pattern, but overall the naming is predictable and readable.
Tool Count3/5
The 149 tools cover a wide range of Google Workspace services, which justifies a larger set. However, this exceeds the typical well-scoped range (3-15 tools), making the server heavy but still organized enough to navigate.
Completeness5/5
The tool set offers comprehensive CRUD and lifecycle coverage for each service (Docs, Sheets, Slides, Drive, Gmail, Calendar, Tasks, Contacts, Forms, Chat, Apps Script, etc.). Only niche features like advanced animations are missing, and most common workflows are fully supported.
Average 4.4/5 across 149 of 149 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like pagination, rate limits, authentication requirements, or performance considerations for large spreadsheets. The agent is left unaware of these aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. It is appropriately short but could be structured to include parameter hints or usage context. No waste, but also no enhancement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description does not provide contextual details like the scope of 'all comments', potential limitations, or relationship to output schema. It feels incomplete for an production tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters with no descriptions, and the tool description does not mention them or add any semantic meaning. Schema description coverage is 0%, so the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'comments from a Google Spreadsheet', indicating the tool returns all comments. The name distinguishes it from sibling tools like 'list_document_comments' and 'list_presentation_comments', but no explicit differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, such as 'manage_spreadsheet_comment' or other listing tools. The description lacks any context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must fully disclose behavioral traits, but it only states the basic action. It does not mention whether the operation is read-only, requires authentication, handles pagination, or what happens on errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise but overly terse. It sacrifices completeness for brevity, lacking essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which may document return values), the description is incomplete. It does not clarify what 'all comments' includes (e.g., replies, metadata) or any usage context. For a simple list tool, at least parameter descriptions are expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the meaning or purpose of the two required parameters (user_google_email, presentation_id). The tool fails to add any value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'list' and resource 'comments from a Google Presentation', clearly identifying the tool's function. It is distinct from sibling tools like list_document_comments by explicitly mentioning presentations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 list_document_comments or manage_presentation_comment. No context about prerequisites or use cases is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits like authentication requirements, rate limits, or that the search relies on a Custom Search Engine setup. It only states it performs a search.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is too minimal, sacrificing useful context. It fits the tool but lacks structure to highlight key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 13 parameters and an output schema, the description is incomplete. It does not mention the return value format or any of the rich options available, requiring the agent to rely solely on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for all 13 parameters. The description adds no additional meaning beyond what the schema provides, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a search using Google Custom Search JSON API, indicating a web search tool. It distinguishes from sibling search tools like search_docs or search_drive_files by specifying the API, but could be more explicit about it being for general web search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as search_docs, search_gmail_messages, etc. The description lacks context about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details beyond the brief 'List all comments.' No annotations are present. It does not disclose whether the operation is read-only, whether it requires specific permissions, whether comments include replies or resolved comments, or whether there are rate limits or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded and delivers the core purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and low schema coverage, the description is too sparse. It does not explain how to obtain the required document_id, what the output format entails (despite an output schema existing), or edge cases like documents with no comments. The context from sibling tools suggests a rich set of comment management features, but this tool's description offers minimal support for an AI agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides two parameters (user_google_email and document_id) with no description coverage (0%). The tool description does not explain the meaning or purpose of these parameters, leaving the agent to infer from names alone. This is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List all comments from a Google Document,' specifying the verb 'list' and the resource 'comments from a Google Document.' This clearly differentiates the tool from siblings like list_spreadsheet_comments and list_presentation_comments, which operate on different Google Workspace document types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like manage_document_comment (which may add or delete comments). There is no mention of prerequisites, contexts, or scenarios where listing comments is appropriate or inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only lists actions without disclosing behavioral traits like write permissions, data shifting on insert/delete, or that freeze replaces existing settings. It lacks detail on side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but effectively front-loads the purpose. It is concise, though packing a list of operations makes it slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 19 parameters, the description is too high-level. It does not explain how parameters relate or typical usage patterns, leaving the agent without sufficient context despite the existence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and parameter descriptions are detailed. The tool description adds little beyond listing categories; it does not enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages sheet-level dimension properties and lists specific actions (resize, auto-resize, freeze, hide/unhide, insert/delete). It distinguishes from sibling tools like format_sheet_range or modify_sheet_values by focusing on dimensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 format_sheet_range for formatting or modify_sheet_values for data changes. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states 'retrieves metadata,' implying no side effects, but does not disclose any behavioral traits such as permissions, error handling, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise and front-loaded. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but adequate given the tool has an output schema (so return values need not be explained). However, it could mention prerequisites like a configured search engine.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the only parameter. The tool description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves metadata about a Programmable Search Engine, which is a specific verb-resource combination. It distinguishes from sibling tools that deal with different resources like contacts or documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. While it is the only tool for search engine metadata, the description lacks context on prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. However, it lacks details such as whether the operation is destructive (overwrites existing formatting), what permissions are required, or if the changes are reversible. It does not mention that applying a list type will convert existing paragraphs, nor does it address potential side effects. The description is too shallow for a complex mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. A single introductory sentence states the core function, followed by two sentences elaborating on capabilities. Every sentence adds value, and there is no unnecessary repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (25 parameters, many optional), the description is somewhat sparse. It covers the main features but omits important context such as the need to obtain indices from inspect_doc_structure, the fact that list_type requires existing paragraphs, and that the operation can be applied in a single call. The presence of an output schema (unseen) slightly reduces the burden, but more completeness would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, meaning each parameter is already well-documented. The description adds overall context but does not significantly enhance individual parameter understanding beyond the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: applying paragraph-level formatting, heading styles, and list formatting to a range in a Google Doc. It lists specific capabilities (headings, lists, alignment, spacing, indentation). The name is descriptive, but it does not explicitly differentiate from sibling tools like modify_doc_text or format_slides_text, which might also handle formatting. A slight improvement would be to contrast with similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites (e.g., requiring indices from inspect_doc_structure), exclusions, or comparison with other paragraph-formatting tools among the many siblings. An agent would need to infer usage from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention side effects (e.g., irreversible changes), required permissions, or rate limits. The schema shows update modes, but the description lacks this context, leaving the agent unaware of nondestructive versus destructive update behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that front-load the core action and consolidation context. Every sentence earns its place without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 17 parameters and an output schema, a two-sentence description is inadequate. It omits critical context such as required conditions for update/delete, update modes, and differentiation from batch operations. The description does not sufficiently equip an agent to handle the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema itself documents all parameters. The description adds no additional meaning beyond the already detailed schema. A score of 3 is appropriate as the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates, updates, or deletes a contact and explicitly positions itself as a consolidated replacement for three prior tools. This makes the purpose unambiguous and distinguishes it from other contact-related tools like get_contact or list_contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as manage_contacts_batch or search_contacts. It only mentions it replaces older tools, which is helpful but insufficient for selecting the right contextual tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only mentions returning runtime/source information but fails to specify if the operation is read-only, what permissions are needed, or any side effects. The temporary nature is noted but insufficient for a diagnostic tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences that are clear and front-loaded. It is efficient but could potentially be more concise without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers purpose and context but lacks details on what exactly is returned or how to interpret the output. The temporary nature is highlighted, but completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter with 0% coverage (no description). The tool description does not mention the parameter at all, failing to add context about the 'user_google_email' parameter's role or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns runtime/source information for diagnosing stale MCP server instances, with a specific verb and resource. It distinguishes itself from sibling tools as the only diagnostic tool focused on runtime verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states its temporary diagnostic purpose and intent to verify which code checkout is loaded. However, it does not provide explicit when-not-to-use instructions or alternatives, though no sibling offers similar functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses the tool modifies the document (converts text to numbered lists) and states idempotency. However, it omits details about permissions required, effect on existing formatting, or behavior with non-standard prefixes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus an idempotency note, which is concise and front-loaded. It avoids unnecessary words but could be slightly more structured with separate sections for parameters and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool modifies documents and has an output schema (unspecified), the description provides enough context for basic usage but lacks details on handling edge cases like existing numbered lists, mixed content, or error scenarios. The mention of 'prompt paragraphs' and 'sub-bullet lists' adds useful specificity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any parameters. The schema covers 75% of parameters with descriptions, but user_google_email lacks a description. The tool description adds no value beyond the schema, failing to clarify the required email parameter or the effect of strip_plain_text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts plain-text 'N. ' step prefixes into a real numbered list with continuous numbering. It specifies the resource (Google Doc or specific tab) and distinguishes this from sibling tools like modify_doc_text or update_paragraph_style.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes idempotency and safety for re-running, providing some guidance. However, it does not explicitly state when to use this tool over alternatives (e.g., when to use apply_continuous_numbering vs modify_doc_text for list formatting).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses basic action and optional features but omits side effects, authentication details, rate limits, and return value behavior (though output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences front-loading the primary action and adding key features. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters and high schema coverage, the description is complete enough for core purpose but lacks usage guidelines and behavioral transparency for a comprehensive evaluation. Sibling tools provide context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is already described. The description adds context for reply drafts and 'Send As', but does not significantly enhance understanding beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a draft email in Gmail, supports new and reply drafts, attachments, and 'Send As' feature. It effectively distinguishes from sibling 'send_gmail_message' which sends immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for drafting, but does not explicitly state when to use vs alternatives like 'send_gmail_message'. No when-not or direct alternative mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discusses color formats and number format types, but does not disclose key behavioral traits: whether formatting is incremental or resets unset properties, if the operation is reversible, or any permission/rate-limit requirements. This is insufficient for a formatting tool with 13 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences, no filler. It is front-loaded with the main purpose, then provides format-specific details, and ends with a practical usage note. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown) and 13 parameters, the description lacks completeness. It does not explain interaction of multiple formatting properties, whether the operation is an update or replacement, or error scenarios. For a complex tool, more context is needed to ensure correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value beyond schema: it clarifies that colors accept hex strings (#RRGGBB) and that number formats follow Sheets types (e.g., NUMBER, CURRENCY, DATE, PERCENT). It also notes the sheet name behavior for range_name. This enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it applies formatting to a range, listing specific categories (colors, number formats, text wrapping, alignment, text styling). It is a specific verb+resource that distinguishes this tool from siblings (which operate on other Google Workspace entities like Docs or Slides).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage context (e.g., 'If no sheet name is provided, the first sheet is used') but does not explicitly state when to use this tool versus alternatives like 'modify_sheet_values' or 'manage_conditional_formatting'. No exclusions or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses recursive copy and sequential processing to avoid rate-limit errors, but fails to mention permissions handling, overwrite behavior, or file size limits. This is adequate but has notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first succinctly defines the action, the second adds key details (tree walk, sequential). No redundant or unnecessary information. Perfectly front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, no annotations, output schema exists), the description covers recursive nature and sequential processing but omits error handling, permission requirements, and what happens on naming conflicts. Sufficient but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, and the existing schema descriptions are clear. The tool description does not add extra meaning beyond the schema for parameters; e.g., 'user_google_email' lacks description in both. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool recursively copies a Drive folder and all its contents to a new location. It explicitly mentions 'sequential' behavior to avoid rate-limit errors, distinguishing it from sibling tools like copy_drive_file (single file) and create_drive_folder (empty folder).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for copying entire folder trees but does not explicitly state when to use it over alternatives like copy_drive_file for single files or create_drive_folder for empty folders. No when-not-to-use guidance is provided, which is a gap given the large list of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 states the tool 'manages' rules but does not disclose behavioral details such as permission requirements, side effects, or limitations. The description is truthful but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the tool's purpose and supported operations with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple actions, 11 parameters) and the presence of an output schema, the description is minimal. It covers the basic purpose but does not explain how actions interrelate or provide context about rule indices and priorities. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 11 parameters have descriptions in the input schema (100% coverage), so the description does not need to add parameter-specific info. It provides a general overview but no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages conditional formatting rules and specifies the supported actions (add, update, delete). It distinguishes itself from sibling tools like format_sheet_range by focusing on rule management rather than direct range formatting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool covers adding, updating, and deleting conditional formatting rules, but lacks explicit guidance on when to use this tool versus alternatives or when not to use it. No exclusions or context-specific recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states the purpose and does not disclose behavioral traits such as permissions, atomicity, error handling, or requirements beyond what is in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is brief but adequate given the rich schema; however, it could add a hint about mapping actions to parameters (e.g., contact_ids for delete) or output structure. The replacement note is useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning to the parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (batch create, update, or delete) and resource (contacts), and distinguishes itself from sibling tools by declaring it is a consolidated replacement for three specific tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it replaces three tools, implying when to use it over them, but does not explicitly compare with singular manage_contact or provide when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds useful behavioral details, notably that the Drive API cannot anchor comments to arbitrary text and that Sheets comments are cell-scoped. It implies mutability but does not discuss permissions, rate limits, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences, using bullet points for actions. It includes a relevant note about API limitations. Minor improvement could be removing 'Actions:' prefix for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the three actions and their parameter dependencies, but omits output/return values (despite an existing output schema), error scenarios, and prerequisites like spreadsheet access permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 explains comment_content and comment_id usage per action, but leaves user_google_email and spreadsheet_id completely unexplained. Action is partially explained via the action list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages comments on a Google Spreadsheet and lists three specific actions (create, reply, resolve). It distinguishes from sibling comment tools by specifying the spreadsheet context, providing a clear verb-resource mapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides per-action parameter requirements (e.g., create needs comment_content) but lacks cross-tool guidance. It does not explicitly state when to use this tool over manage_document_comment or manage_presentation_comment, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds some behavioral context (e.g., supports replies, 'Send As' feature) but does not disclose authentication requirements beyond the required user_google_email, potential failure points (e.g., alias not configured), or side effects. The description is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and contains no fluff. Every sentence adds value, making it highly efficient for an agent to quickly understand the tool's core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters with 100% schema coverage and an output schema, the description covers main capabilities (new emails, replies, attachments, aliases). It lacks details on error handling or post-send behavior, but for a sending tool with rich schema, it is sufficiently complete for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description summarizes key features like replies and attachments but does not add significant meaning beyond the schema descriptions. It provides high-level context but not deeper per-parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'sends', the resource 'email using the user's Gmail account', and distinguishes from siblings by specifying Gmail-specific features like 'Send As' and replies, setting it apart from draft_gmail_message and send_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description indicates it supports new emails, replies, and aliases, it lacks explicit guidance on when to use this tool versus alternatives like draft_gmail_message or send_message. No 'when not to use' or comparisons are provided, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 OAuth write scope, but does not mention potential side effects (e.g., overwriting existing named ranges with the same name, behavior on invalid range, or scope of effect beyond the spreadsheet). The description is adequate for a simple creation tool but could be more transparent about conflict resolution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and provides examples in a well-structured manner. However, it is slightly verbose, including details like the Data > Named ranges sidebar and autocomplete behavior. Every sentence adds value, but some conciseness is sacrificed for thoroughness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (as per context signals), the description need not explain return values. It covers the concept, usage in formulas, and OAuth requirement. However, it lacks information on error handling (e.g., duplicate name or invalid range) and does not reference any prerequisites beyond auth. Overall, it provides solid context but has minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, and the schema itself provides detailed descriptions for parameters like 'name' and 'range_name'. The tool description adds no new parameter semantics beyond the schema; it provides usage context (e.g., how to use named ranges in formulas) but does not elaborate on the parameters themselves. Hence, it meets the baseline for the given coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Define a named range that formulas and scripts can reference by name.' It provides specific examples and explains the benefit of readability and reference stability. This distinguishes it from sibling sheet tools like 'add_sheet_data_validation' or 'format_sheet_range'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to make formulas more readable, allow cell movement without breaking references) and notes the required OAuth scope. However, it does not explicitly mention when not to use it or compare to alternatives like direct A1 references. The context is clear but lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behaviors: returns Markdown, includes comment anchor text by default, and comment mode options. However, it does not mention safety/read-only nature explicitly, potential errors, or rate limits, leaving some gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at about 6 sentences, well structured with the main action first, then distinct differences, followed by comment behavior. Every sentence adds value without repetition or waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 parameters, output schema exists), the description covers the primary output format and comment handling. It does not explain the return value structure (handled by output schema) or error cases, but for a read tool, it is mostly complete. A minor gap is lack of explicit read-only guarantee.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters in detail. The description adds context about comment anchor text but does not provide significant additional meaning beyond the schema for most parameters. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads a Google Doc and returns it as clean Markdown with optional comment context. It explicitly distinguishes from the sibling tool get_doc_content which returns plain text, making the purpose highly specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly differentiates from get_doc_content by noting this tool preserves formatting, providing clear guidance on when to use it. However, it does not address exclusions or other alternative tools (e.g., inspect_doc_structure, export_doc_to_pdf), though the main alternative is well covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions required OAuth scope and visibility to user. Does not describe pagination behavior or output structure; relies on schema for parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no fluff. Front-loaded with purpose, followed by explanation and usage hint. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, and scope. With output schema present, return values are assumed documented. Could mention that output is a list of group objects, but overall adequate for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-documented in schema. Description adds no additional meaning for parameters beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states purpose: list contact groups (labels). Distinguishes from siblings get_contact_group and manage_contact_group by specifying it's for discovering group IDs. Provides concrete examples ('Family', 'Starred').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises use to discover group IDs for other tools. Implicitly indicates not to use if you already have the ID. Lacks explicit 'when not to use' but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes output format (flat tree with indentation for nesting), document order, and read-only nature. Specifies OAuth scope. No annotations provided, so description carries the burden adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three paragraphs, front-loaded with key purpose. Some redundancy but overall efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, scope, and hierarchy representation adequately for a list tool. Has output schema, so return structure not required. Minor omissions like handling of empty documents, but still complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 2 parameters with only 50% schema description coverage. Description does not add details about 'user_google_email' or further clarify 'document_id' beyond what's in schema. Fails to compensate for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List all tabs in a Google Doc, including nested child tabs, as a flat tree.' Explains purpose for discovering IDs, titles, and hierarchy. Distinguishes from sibling tools that require a tab_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'call this first to discover IDs, titles, and the tab hierarchy.' Provides context for when to use. Lacks explicit when-not-to-use, but guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies read-only behavior via 'List', mentions OAuth scope, but does not disclose pagination, rate limits, or exact behavior beyond listing. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states purpose, second gives context about filters, third provides usage guidance and scope. No fluff, well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description adequately covers purpose, usage context, and scope. Could mention if all filters are returned or if there is pagination, but overall sufficient for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no extra meaning. Baseline 3 is appropriate as the schema already describes the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('server-side Gmail filters'). It differentiates from sibling tools like manage_gmail_filter and list_gmail_labels by specifying filters and use for audit/discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to use before calling manage_gmail_filter for delete, and mentions required OAuth scope. Does not explicitly state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies read-only behavior via 'list' and mentions the OAuth scope, but does not disclose potential limitations like pagination, rate limits, or behavior when no tables exist. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first for core purpose, second for clarification, third for usage guidance and scope. No unnecessary words, well structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with only 2 required parameters and an output schema present. Description covers purpose, usage hint, and scope. Could briefly mention that output is a list of tables, but the existence of output schema makes this acceptable. Overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so schema itself fully documents parameters. Description adds no extra semantic detail beyond the schema, meeting baseline but not exceeding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists all structured tables (native Sheets tables) in a spreadsheet, distinguishing them from bounded ranges. It also notes the primary use case of discovering table_id for append_table_rows, making the purpose highly specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use the tool (to discover table_id before append_table_rows) and notes the required OAuth scope. However, it does not mention when not to use or provide alternatives, slightly limiting completeness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details side effects for each action, including the nuance of delete_contacts. It also mentions the OAuth scope requirement. It does not cover rate limits or error conditions, but for this context, it is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with purpose, and each sentence serves a distinct function: purpose, side effects, and usage alternatives/auth. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters) and the presence of an output schema, the description covers purpose, all action behaviors, deletion nuance, reading alternatives, and auth. It omits error handling and prerequisites beyond auth, but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds marginal value beyond the schema by summarizing actions, but each parameter is already well-described in the schema. No new parameter semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create, update, delete, or modify members of a contact group.' It uses specific verbs and specifies the resource (contact group), effectively distinguishing it from sibling tools like list_contact_groups and manage_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'For reading use list_contact_groups / get_contact_group,' providing a clear when-not scenario. However, it doesn't differentiate from sibling mutation tools like manage_contact (individual contacts) or manage_contacts_batch, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 a key limitation (Drive API cannot anchor comments to specific text) and specifies requirements for each action. However, it omits permission needs, rate limits, error behavior, and idempotency details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using bullet points for clarity. Every sentence is relevant and there is no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values are not needed. The description covers the action-specific parameters well and includes a key limitation. However, it lacks details on the required parameters user_google_email and document_id, and could benefit from examples or format constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by explaining when comment_content and comment_id are needed for each action. However, it does not explain user_google_email or document_id beyond being required, leaving some parameters underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages comments on a Google Document with three specific actions (create, reply, resolve). It distinguishes from sibling tools like list_document_comments and manage_presentation_comment by focusing on comment management actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to modify document comments but lacks explicit guidance on when to choose this tool over alternatives. No exclusions or alternative tool mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It specifies required parameters for each action and mentions a key API constraint (no arbitrary text anchoring). However, it omits permission requirements, error handling, or side effects like notifications. The 'resolve' action is ambiguous (marks resolved vs deletes).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear header, bulleted actions, and a note. Every sentence is informative with no repetition or fluff. Structure allows quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return values need not be described. The description covers core functionality and a key limitation. However, it lacks comparison with similar sibling tools (e.g., manage_document_comment) and does not explain the effect of 'resolve' (e.g., if comments can be unresolved). Minor gaps for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains that comment_content is needed for create and reply, comment_id for reply and resolve, and action values. It does not detail user_google_email or presentation_id, but those are standard. Overall, it adds substantial value beyond bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it manages comments on Google Presentations and lists three specific actions (create, reply, resolve). The inclusion of 'Slides comments are element-scoped via the API' differentiates it from document and spreadsheet comment tools, as seen in sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to create, reply, or resolve comments) but does not explicitly compare with alternatives like list_presentation_comments or similar tools for docs/spreadsheets. It provides no guidance on when not to use it or best practices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It mentions the OAuth scope required and the 'primary' alias, but lacks details on pagination, filtering, or any side effects (though none expected). Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences with the purpose first, followed by usage context and OAuth requirement. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description doesn't need return details. It covers purpose, usage, OAuth scope, and the 'primary' alias. Complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'user_google_email,' and the description adds no additional meaning beyond the schema's description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List every calendar the user owns or has access to' with a specific verb and resource. It distinguishes from siblings by explaining its role in providing calendar IDs for other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to discover calendar IDs before calling get_events, manage_event, or create_calendar,' providing clear when-to-use guidance. It does not list when not to use, but the positive guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 that all actions mutate permissions, transfer_owner permanently changes ownership, and notification emails are sent per send_notification. It also notes the OAuth scope requirement. This provides substantial behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of five focused sentences, front-loading the core action and then covering side effects, alternatives, and auth requirements. It is efficient but could be slightly more concise by grouping related information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (14 parameters) and the presence of an output schema, the description provides a solid overview of functionality, side effects, and usage alternatives. It adequately covers the key behavioral aspects, though it could mention handling of different actions more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional parameter-level meaning beyond the schema definitions, but it does explain side effects and relationships (e.g., send_notification applies to grant/grant_batch). This is adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Grant, batch-grant, update, revoke, or transfer ownership on a Drive item,' providing a specific verb and resource. It distinguishes itself from sibling tools like get_drive_file_permissions (read-only) by explicitly naming an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers explicit guidance by stating 'For read-only inspection use get_drive_file_permissions' and mentions the required OAuth scope. However, it does not fully elaborate on when to choose this tool over other mutation tools like set_drive_file_permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Details document body indexing (starts at 1, empty doc length 2), markdown parsing behavior, and sequential workflow. With no annotations, description effectively discloses structural and behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three paragraphs with no wasted sentences. Front-loaded with main purpose, then structural details, then workflow. Efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description need not explain return values. Covers creation, structure, and complete workflow guidance with sibling tool references. Sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, so baseline 3. Description adds marginal context about document indexing but largely restates schema info. No significant additional parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates a new Google Doc with optional initial content. Specifically names the resource and action, distinguishing it from siblings like batch_update_doc and insert_doc_markdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit after-creation workflow: use batch_update_doc for rich content and inspect_doc_structure before formatting. Implicitly differentiates when to use this vs other tools, though no direct 'when not to use' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses side effects (creates new file owned by user in My Drive root) and auth requirement (spreadsheets OAuth scope). It doesn't describe return value, but output schema exists. Minor omission of whether creation is reversible or conflicts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus side effect/alternatives, no wasted words. Front-loaded with purpose, then important context. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, the description sufficiently covers purpose, side effects, alternatives, and auth. It doesn't explain return values but that's covered by schema. Lacks mention of what happens if file with same title exists, which could be added for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for all 3 parameters. The description adds no additional detail beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new empty Google Spreadsheet in My Drive with specific verb and resource. It distinguishes from siblings like create_sheet (adds tabs to existing), create_drive_file, and import_to_google_doc, providing precise differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use this tool vs alternatives (create_sheet for tabs, create_drive_file/import_to_google_doc for .xlsx uploads) and mentions required OAuth scope. However, it doesn't explicitly exclude all inappropriate uses, such as editing existing files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. Describes side effects (freezes code, creates versionNumber), immutability (cannot edit/delete), required OAuth scope. Could mention return value, but output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with clear action sentence, followed by essential side effects, constraints, and references. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are covered. Description addresses side effects, immutability, related tools, and auth scope. Lacks mention of prerequisite script project existence, but overall sufficient for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented in schema. Description adds contextual meaning but no extra parameter-specific details beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly uses verb 'create' with specific resource 'immutable version snapshot of an Apps Script project', distinguishing it from sibling tools like list_versions (listing) and manage_deployment (deployment management).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use this tool (create a snapshot for deployment), and references alternatives: manage_deployment for pinning and list_versions for listing. Does not explicitly state prerequisites or exclusions, but adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the type of formatting applied but does not disclose potential side effects (e.g., whether formatting overwrites or merges with existing styles, behavior for invalid indices, or scope of changes). The parameter semantics in the schema are detailed, but the description could add more context on idempotency and error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus targeted alternatives), front-loaded with the core purpose, and every sentence earns its place. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage guidelines, and parameter intent. It does not mention the return value, but an output schema exists (as per context), reducing the need. It could briefly note behavior for start/end indices (e.g., omitting indices formats all text). Overall, sufficiently complete for a straightforward formatting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond listing the formatting attributes (bold, italic, etc.), which are already detailed in the schema. No extra semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies character-level formatting to text inside a slide element, with specific examples (bold, italic, font, color). It explicitly distinguishes from sibling tools format_slides_paragraph, style_slides_shape, and format_all_slides_text, leaving no ambiguity about its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives ('use format_slides_paragraph for alignment/spacing/bullets, and style_slides_shape for the shape outline/fill/shadow. For bulk re-style across every text element use format_all_slides_text'). It also mentions the required OAuth scope, helping the agent assess prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It explicitly states the tool generates code rather than performing the trigger creation, which is a key behavioral trait. While it doesn't detail output format or limitations, it sufficiently discloses the core non-obvious behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, with the first sentence stating the purpose and the second providing rationale. It is front-loaded and contains no unnecessary words, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown) but the description implies the output is Apps Script code. It covers the essential 'why' and 'what' adequately for a simple code generation tool. Missing details about output format or example usage are minor gaps, keeping it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 3 parameters, so the schema already provides detailed parameter semantics. The description does not add additional parameter information beyond context, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('generates') and the resource ('Apps Script code for creating triggers'). It distinguishes this tool from siblings by emphasizing that it generates code rather than performing direct API calls, which is unique among the listed sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains why this tool is needed: the API cannot create triggers directly, so code generation is required. This provides clear context for when to use it, though it does not explicitly list when not to use or mention alternatives, which would warrant a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses read-only nature via OAuth scope, limitations on content retrieval, retention policy, and default page_size behavior with no pagination token support. Adds significant transparency beyond structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured and informative at about 150 words. Every sentence adds value, no fluff. Could be slightly tighter but remains clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with an output schema (not shown but referenced), the description provides complete context: purpose, parameters, behavioral traits, limitations, sibling reference, and security/scope info. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (2 of 3 params described). Description adds no additional parameter details beyond schema; however, schema descriptions for file_id and page_size are detailed. The missing user_google_email parameter is not addressed. Baseline 3 is appropriate since schema does most work but leaves a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists revision history for a Drive file, newest first, and lists specific return fields (ID, timestamp, user info, size, MIME type, pinned status). Distinguishes itself from sibling tool restore_drive_revision by stating its purpose is to discover revision IDs before calling that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it (discovering revision IDs before restore, auditing changes) and provides OAuth scope. Mentions limitations (Google-native files not restorable, retention policy). Missing explicit 'when not to use' but context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behavioral details: uses Gmail batch API (25 per request), auto-chunked, fallback to sequential fetches, and required OAuth scope. Missing details on error handling for partial failures or rate limits, but still informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words. Front-loaded with main purpose, followed by key advantages and requirements. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch, chunking, fallback), the description covers essential behavior. Output schema exists so return value is documented. Could mention that it fetches thread content (including messages), but still adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds little new parameter info. The description reinforces chunking behavior already noted in schema for thread_ids. No additional semantics beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Fetch many Gmail threads in one batch', distinguishing it from the singular get_gmail_thread_content. The description explicitly contrasts with looping over get_gmail_thread_content, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Prefer this over calling get_gmail_thread_content in a loop', providing a clear usage rule. It details batch API usage, auto-chunking, and fallback behavior. However, it could explicitly state when not to use (e.g., for a single thread).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it inserts a hyperlink and requires OAuth, but does not disclose potential side effects (e.g., modifying document content, overwriting existing text at the index). More detail on behavior would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences), front-loaded with the main purpose, and each sentence adds essential information: action, sibling alternatives, and OAuth requirement. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers core purpose, usage guidelines, and OAuth. The input schema is fully described, and there is an output schema (not shown). Missing mention of document modification side effects, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal meaning beyond the schema; it only states 'simple hyperlink' without elaborating on parameter details. No significant added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'insert', the resource 'clickable hyperlink text', and the location 'at a given document index'. It distinguishes from sibling tools by naming alternatives (insert_doc_file_chip, insert_doc_person_chip) and their use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('simple hyperlink') and when to use alternatives ('for a Drive-file smart chip' and 'for a person @mention chip'). It also mentions the required OAuth scope, providing clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fully explains the tool's manual nature and its relationship to automatic authentication. Could mention potential side effects of improper use, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured with clear lead sentence followed by bullet-pointed usage conditions. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, return values don't need explanation. However, the tool has 2 parameters with zero schema descriptions, and the description doesn't compensate for that gap, leaving the agent to guess parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet description offers no explanation of the two parameters ('service_name' required, 'user_google_email' optional). The schema itself lacks descriptions, so the agent must infer parameter meanings from name only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Manually initiate Google OAuth authentication flow' using specific verb and resource. It distinguishes from sibling tools by explicitly contrasting with automatic authentication and providing usage scenarios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use conditions (re-authenticate, proactive, retry) and when-not (most cases just call the needed tool). Also notes it's legacy and disabled when OAuth 2.1 is enabled, giving clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects (rename, move, trash, star) and notes that trashing is reversible. It also warns that changing mime_type rarely works without content. With no annotations provided, the description carries the transparency burden and does so adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with each sentence adding distinct information: purpose, side effects, exclusions, reversibility, and authentication. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main aspects of the tool: what it updates, side effects, what it does not do, reversibility, and auth scope. An output schema exists, so return values are handled externally. A minor gap is lack of explanation for add_parents/remove_parents move behavior, but the schema covers that detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to explain individual parameters. It adds value by grouping parameters into categories (metadata, parents, flags) and adding clarifying notes like the reversibility of trashed, but this does not significantly exceed the schema's information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates metadata, folder parents, and flags. It distinguishes itself from content creation tools by explicitly stating it does NOT upload content, and mentions alternatives like create_drive_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when not to use (for content uploads) and mentions the required OAuth scope. It could be more explicit about when to prefer this over other update tools, but the context is clear given the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 key behaviors: mutation, auto-extending range, automatic type conversion (bool, number, formula), and OAuth scope requirement. It lacks explicit error conditions or idempotency, but covers essential traits well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs. It front-loads the purpose and uses clear, non-redundant language. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (mutation with typing) and presence of an output schema, the description covers purpose, side effects, typing, alternatives, and auth scope. It omits error handling and return value details, but is largely complete for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema. It mentions auto-extending range related to values, but no additional parameter-level details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Append rows to a structured Sheets table, auto-extending its range.' It uses a specific verb+resource and explicitly distinguishes from the sibling tool modify_sheet_values for plain range writes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (for structured table appends) and when not to (use modify_sheet_values for plain range writes). It also mentions prerequisites like table_id from list_sheet_tables.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions side effects ('creates a new Drive file') and the required OAuth scope ('drive.file'), adding useful behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with core purpose. Each sentence adds distinct value: purpose, side effects, alternatives, and auth requirement. Minor redundancy but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core action, alternatives, and auth requirement. With good schema coverage and output schema, description is nearly complete. Could mention mutual exclusivity of content and fileUrl, but schema already does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description only hints at parameters ('from content, a URL, or a local path') without adding significant meaning beyond the schema's detailed descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uploads a file to Drive from content, URL, or local path, and distinguishes itself from sibling tools like import_to_google_doc and create_doc for specific use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use alternatives: 'To convert source files... use import_to_google_doc instead. For a brand-new empty Google Doc/Sheet/Slide use create_doc/create_spreadsheet/create_presentation.' Also notes the required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the side effect of creating a Drive project and the required OAuth scope. However, it omits details like project privacy, location, rate limits, or whether the user must be the owner. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences, front-loaded with the core purpose. Each sentence adds distinct information: purpose, side effects, parameter usage, and prerequisites. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter creation tool with an output schema, the description covers side effects, prerequisites, optional parameter guidance, and references a follow-up tool. It fully equips the agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explicitly stating that omitting parent_id creates a standalone project, which complements the schema's description. It clarifies the decision point for using the optional parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb-resource pair: "Create a new (standalone or container-bound) Apps Script project." It distinctly specifies the resource (Apps Script project) and differentiates from siblings like list_script_projects, update_script_content, and delete_script_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the optional parent_id (bound script) versus omit (standalone), mentions the prerequisite OAuth scope, and directs to update_script_content for adding files. It lacks explicit 'when not to use' statements but provides adequate contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses it creates and populates reliably, data format rules, and suggests verification. Does not detail potential failures or side effects, but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with steps and critical notes, front-loaded. Some redundancy (example repeats format requirements) but overall well-organized and helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (6 params, output schema exists, no annotations), description is comprehensive. Includes workflow, data format, index criticality. Return values covered by output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but description adds value with data format example, index source requirement, and bold_headers default behavior. Provides meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Creates a table and populates it with data' – specific verb and resource. Distinguishes from siblings like append_table_rows which appends to existing tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit mandatory workflow (inspect_doc_structure first, use total_length as index) and data format requirements. Lacks explicit when-not-to-use or alternatives, but steps are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it operates on the entire document without index calculation, and implies all occurrences are replaced. However, it does not explicitly confirm replacement behavior for multiple occurrences or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear paragraphs, front-loaded with the main action, and includes examples. It is concise but could be slightly shorter without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, safety, use cases, and alternatives adequately. It notes an output schema exists, so return value details are not required. Lacks explicit note about replacing all occurrences, but context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all parameters. The description does not add new parameter meanings beyond the schema, but provides contextual usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds and replaces text throughout a Google Doc, distinguishes from siblings like batch_update_doc and modify_doc_text, and provides specific use cases (e.g., replacing placeholders).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends this tool for safe text updates without indices, and advises using batch_update_doc for building documents from scratch, providing clear 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden. It discloses side effects (writing file, temporary URL), stateless mode behavior (base64 preview), and ephemeral nature of attachment IDs. This is comprehensive for the tool's safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a main sentence followed by bullet-point-like details. Each sentence adds value, though it could be slightly more compact. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (file download, multiple modes), the description covers key aspects: download vs URL, stateless mode, ephemeral IDs, and OAuth scope. Output schema exists, so return values are handled. Minor omissions like file size limits are acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all three parameters. The description adds context about attachment_id needed from parent message, but this is also in the schema. Minimal extra value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Download a Gmail attachment'. It specifies the verb (download) and resource (Gmail attachment), and distinguishes it from siblings like get_gmail_message_content by focusing on attachment content rather than the message body.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: to download an attachment, and notes that attachment IDs are ephemeral, advising to re-fetch the parent message before calling. It also mentions required OAuth scope. However, it does not explicitly state when not to use this tool or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that the underlying representation is a linked email, the client-side conversion to a rich chip, fallback behavior, and how the chip appears in `get_doc_smart_chips`. It does not mention reversibility or idempotency, but overall is thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized and well-structured: primary action first, then technical details, scope requirement, sibling references, and a note. It could be slightly more terse, but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate parameter count (5), presence of output schema, and lack of annotations, the description adequately covers behavior, requirements, and alternatives. It explains the rendering nuance that is critical for correct usage, and the existence of an output schema covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so baseline is 3. The tool's main description does not add parameter-specific semantics beyond what the schema already provides. For example, the `index` parameter's default and use with `tab_id` is explained in the schema, not in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Insert an @mention-style person chip'), the resource (person chip), and the context (specific position in a document). It immediately distinguishes from siblings by naming `insert_doc_file_chip` and `insert_doc_link` as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the required OAuth write scope and provides clear guidance on when to use alternative tools (Drive-file chip, plain hyperlink). It also notes a behavioral quirk (chip only renders client-side) that affects usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the reported fields (function name, status, start time, duration) and required OAuth scope, giving adequate behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences, each adding value: purpose, use case, reported fields, and scope requirement. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description adequately covers purpose, use case, and output fields. Requires no additional context for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% so baseline is 3; description adds marginal value by listing output fields but does not further clarify parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('Apps Script executions'), and clearly states the scope ('across all scripts or one'), making it distinct from sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear use cases ('debugging failed runs or auditing triggered executions') but does not explicitly mention when not to use or compare alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description explains the underlying mechanism (Drive API search with specific mimeType) and the required OAuth scope. This compensates for lack of annotations, though no mention of pagination limits or performance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose. No redundant information; every sentence adds value (purpose, reason for approach, alternatives, scope requirement).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 purpose, underlying method, alternatives, and auth requirements, making it fully informative for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add per-parameter details beyond schema, but explains the overall Drive API approach, which provides context. No additional semantic value for individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with a clear verb-resource pair ('Find Apps Script projects') and distinguishes from sibling tools like get_script_project and get_script_content by stating its scope (scanning Drive vs content retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states why this tool is used (no native list endpoint in Apps Script API) and points to alternatives for content (get_script_project/get_script_content). Does not explicitly list when not to use, but the context is sufficient. Also notes required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It discloses side effects: 'mutating actions may auto-decline existing/incoming invites based on auto_decline_mode.' It also notes OOO events live on primary calendar and require 'calendar.events' OAuth scope. Lacks rate limits but covers key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with three key sentences: purpose, sibling distinction, and side effects/requirements. It front-loads the purpose. Slightly verbose with the side effects paragraph, but no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complexity is high (14 params, output schema exists). Description covers purpose, sibling tools, side effects, scope, and calendar placement. It does not detail return values, but output schema handles that. Missing maybe an example usage, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value beyond schema: it explains that OOO events auto-decline invitations and that calendar_id must be primary (echoed in param description). Also clarifies that start_time/end_time can accept date-only strings. Provides context for action parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create, list, update, or delete Out of Office events,' using a specific verb and resource. It distinguishes itself from siblings 'manage_event' and 'manage_focus_time' by explicitly naming them as alternatives for normal events and focus-time blocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides explicit guidance: 'For normal events use manage_event; for focus-time blocks use manage_focus_time.' It also explains when OOO events appropriate (auto-decline, presence change). However, it lacks explicit 'when not to use' beyond the sibling references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the key side effect: 'replaces any existing validation on the range.' Without annotations, this is critical. Could mention more edge cases or performance, but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first states purpose, second adds side effect, third provides alternatives and auth requirement. No unnecessary words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, side effect, alternatives, and auth. Output schema exists, so return values are handled. Minor gaps in edge-case behavior, but overall complete for usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented. The description adds only a high-level summary (dropdowns, bounds, formulas), not enhancing individual parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Apply' and the resource 'data-validation rule to a range', with examples (dropdowns, bounds, formulas). It distinguishes itself from sibling tools like manage_conditional_formatting and protect_sheet_range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (for data validation) and when not (conditional formatting -> manage_conditional_formatting, cell protection -> protect_sheet_range). Also notes the required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool mutates label sets on every message and notes the Gmail API limit not enforced. While it doesn't detail error handling or atomicity, it provides sufficient behavioral context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three compact sentences: purpose, side effects and API detail, sibling tool and auth. Every sentence adds value with no redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not cover return values. It adequately covers purpose, behavioral traits, limits, alternatives, and auth. Minor gaps like error handling or batch size enforcement are acceptable for a batch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, with each parameter clearly described (e.g., message_ids from search, label IDs with system/user distinction). The description adds no additional parameter details beyond the schema, so baseline score applied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool adds or removes labels on many Gmail messages, clearly defining the action and resource. It also distinguishes from the sibling tool by noting that single messages should use modify_gmail_message_labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (batch operations) and when not to (single messages, directing users to modify_gmail_message_labels). It also mentions the Gmail API limit of 1000 IDs and the required OAuth scope, helping agents select correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects (creates calendar, adds to list) and required OAuth scope. With no annotations, this is helpful, though it could mention limits or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with purpose, followed by side effects, guidance, and scope. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, the description covers purpose, side effects, scope, and returns (implied calendar_id). Missing output schema details but adequate for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers all parameters with detailed descriptions (100% coverage). The description adds no extra parameter-specific meaning beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool creates a secondary calendar for the user, with specific verb and resource. It differentiates from siblings like list_calendars (listing) and manage_event (events).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (creating a calendar) and when not to (use manage_event for events, web UI/ACL for sharing), providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses ownership side effects, relationship to create_drive_file, and OAuth scope requirement. Does not mention error conditions or rate limits, but sufficient for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the primary action. Every sentence adds necessary context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains purpose, side effects, and next steps. Implies return value (ID) but does not detail the output schema. Slightly incomplete for a tool with output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds value by explaining ownership implications of parent_folder_id and clarifying that forward slashes in folder_name are literal. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new folder in Drive (or inside a shared drive)', specifying the verb and resource. It distinguishes from sibling tools like create_drive_file by mentioning folder creation and shared drive context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes side effects (ownership) and explicitly directs to use create_drive_file for uploading files, indicating when to use this tool vs alternatives. Mentions required OAuth scope but lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects (creates empty form owned by user) and required OAuth scope. With no annotations, the description carries the transparency burden and does it well, though it could mention failure modes or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, side effects/alternatives, and scope. No unnecessary words, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a creation action with an output schema, the description covers creation, side effects, follow-up steps, and authorization. Minor omission: does not explain that the created form is empty and requires additional calls, but that is implied by the batch_update_form reference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description only reiterates 'title and optional description' which is already in the schema. It does not add extra context for the user_google_email or document_title parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new Google Form with a title and optional description. It distinguishes itself from siblings like batch_update_form (modifies) and get_form (reads) by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (to create a new form) and provides alternatives for adding items (batch_update_form) and inspecting (get_form). Also mentions required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description discloses side effects (creates file in My Drive root, contains one default slide) and the OAuth requirement, but omits details about the return value or persistent behavior beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five short, front-loaded sentences efficiently convey purpose, side effects, alternatives, and requirements without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the essential context for creating a presentation, including differences from related tools and a prerequisite. The presence of an output schema reduces the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no new semantic meaning beyond what the schema already provides for the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new empty Google Slides presentation') with a specific verb and resource, differentiating it from siblings like 'copy_drive_file' and 'batch_update_presentation'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions when to use alternative tools ('To add more slides use batch_update_presentation with createSlide; to duplicate an existing deck use copy_drive_file') and the required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses behavior (adds text box, positions in EMU, requires OAuth scope) but lacks details on potential side effects, error cases, or limits (e.g., max text length). Still, it covers key behavioral traits sufficiently.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise at 5 sentences, front-loaded with purpose and alternatives, then units and auth. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no annotations, and existing output schema, the description is fairly complete. It covers purpose, usage guidelines, units, and auth. Lacks details on behavior when optional parameters are omitted or output format, but schema and output schema compensate. Good overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. Description adds context about EMU units and OAuth scope but does not enrich individual parameter meanings. Baseline of 3 is appropriate since schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Add a text box to a slide with initial content and position' and distinguishes from sibling tools (create_slides_shape for shapes, batch_update_presentation for editing existing text). The verb+resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (for text content), and when to use alternatives (create_slides_shape for geometric shapes, batch_update_presentation for editing existing text). Provides clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that attachment bytes are not returned and mentions the required OAuth scope. It could additionally state if the body can be large, but the information is adequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero wasted words. First sentence states purpose, second provides usage alternatives, third clarifies exclusions and scope. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 adequately covers return content (headers, body) and exclusions (attachments). It lacks mention of potential size limits but is otherwise complete for a single-message retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds little beyond schema: it mentions 'headers and body' which contextualizes the output, but body_format is already detailed in schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve one Gmail message's headers and body', providing a specific verb and resource. It distinguishes from siblings like get_gmail_messages_content_batch and get_gmail_thread_content by explicitly specifying use for a single message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use and when-not-to-use guidance, recommending alternatives for multiple IDs (batch), conversations (thread), and attachments. It also mentions required OAuth scope, aiding correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes that sender names are resolved via People API and lists required OAuth scopes. However, it does not mention pagination behavior or rate limits. Since no annotations are present, the description carries the burden; it covers the most important behavioral aspects but lacks details on limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with four sentences. Main action is stated first, followed by usage guidelines and behavioral notes. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, required fields are stated, and output schema exists, the description covers purpose, usage, and key behaviors. Missing explicit details on pagination and default ordering beyond what schema provides, but largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with parameter descriptions. The description does not add additional meaning to parameters beyond what is in the schema. Baseline 3 applies as schema already provides parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List messages in a Google Chat space with sender names resolved' and specifies 'Use this to read a room/DM's recent messages'. It distinguishes from siblings like search_messages, send_message, and download_chat_attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool and when not, with alternative tool names: 'For text search across spaces use search_messages. For sending messages use send_message. For attachment downloads use download_chat_attachment.' Also mentions required OAuth scopes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It declares read-only nature, safe for repeated calls, and required scope. It does not specify error behavior (e.g., missing notes) or rate limits, but covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each serving a purpose: action statement, output description, use case and alternative, authority and safety. No redundancy, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, authority, and safety. Assumes output schema exists (not shown) so return details are adequately described as plain-text. Missing edge-case handling but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (3 of 4 params have descriptions). The description adds context that the tool works on a single slide but does not elaborate on parameters beyond what schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it reads speaker notes from a single slide, specifies the return type (plain-text), and distinguishes from sibling tool update_slides_speaker_notes. Use cases for auditing/exporting are mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (auditing/exporting notes) and when not (for modifications, use update_slides_speaker_notes). Also lists required OAuth scope and confirms it's safe to call repeatedly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses permanent deletion (no API undo) and inability to delete the last remaining sheet. No annotations provided, so description carries full burden. Lacks details on other behaviors like rate limits or auth specifics beyond scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Six well-structured sentences with no redundant information. Each sentence adds value: purpose, summary, alternatives, limitations, and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and high schema coverage, description covers key aspects. Some minor gaps like error handling but overall complete enough for moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83% and already explains parameters well (e.g., action options, sheet_id preference). Description adds minimal extra value beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool renames, deletes, or duplicates sheet tabs. It distinguishes from siblings by mentioning 'create_sheet' for new tabs and 'batch_update' for reordering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (three tab lifecycle operations) and when not to (creating: use create_sheet; reordering: use batch_update). Also notes required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses side effects (mutates state), special behavior (move reparents/relocates), and OAuth requirement. Lacks details on error handling or deletion cascading, but sufficient for typical CRUD.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with front-loaded purpose, followed by side effects, usage tip, sibling reference, and auth requirement. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters and 4 actions with no annotations, description covers actions at high level, provides specific usage tips, and references sibling tool. Output schema exists, so return details not needed. Minor gaps: could mention error handling, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds value beyond schema by clarifying usage patterns (e.g., completing task, ordering via 'previous'), improving parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool creates, updates, deletes, or moves tasks, with clear verb+resource. It distinguishes from manage_task_list by noting 'For list-level operations use manage_task_list.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides when-to-use context (e.g., completing a task via action='update' with status='completed') and a sibling tool reference (manage_task_list). Does not explicitly exclude read-only alternatives like get_task or list_tasks, but usage is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses side effects (overwriting existing cells) and explains that the range extent determines overwrite area and clears leftover cells. It could mention atomicity or limits, but provides sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no waste. The first sentence states purpose, the second covers side effects and alternatives, and the third notes OAuth scope. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 params, 3 required) and the presence of an output schema, the description covers purpose, side effects, alternatives, and scope. It does not need to explain return values. It is complete enough for correct selection and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra detail beyond the schema for parameters, but the schema already documents each parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes, overwrites, or clears values in an A1 range, with a specific verb and resource. It distinguishes itself from siblings by naming append_table_rows and format_sheet_range as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when not to use this tool (append rows, formatting) and points to specific alternatives. It also mentions the required OAuth scope, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key traits like deployment requirement, dev_mode ownership, and OAuth scopes, but does not mention potential side effects, error handling, or return value behavior. Since no annotations are present, the description carries the full burden but omits important safety warnings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: three sentences covering purpose, prerequisites, dev_mode note, alternative tool, and scopes. Front-loaded and no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and a complex tool with 5 params, the description covers purpose, prerequisites, alternative, scopes, and param nuances. Missing details on error/timeout handling, but output schema likely fills return value gap. Still solid for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, and the tool description adds context beyond schema: deployment requirement, dev_mode owner-only, and scope needed. This elevates the baseline of 3 to a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute a function inside an Apps Script project,' specifying the verb and resource. It distinguishes from siblings like manage_deployment by referencing deployment management separately, ensuring no confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisites (API-executable deployment), dev_mode restrictions (owner only), and directs to manage_deployment for deployment management. Also notes required OAuth scopes, providing clear guidance on when and how to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the client-side matching mechanism, server-side createTime filtering, per-space fetching, and the resolution of senders via People API. It omits mention of rate limits or pagination behavior, but the effect of page_size is described in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs. The first sentence captures the core purpose. Every sentence adds value: scope, mechanism, sibling reference, and auth requirements. No redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity (6 parameters, client-side search across spaces) and an output schema exists. The description covers the algorithm, scope distinction, and OAuth scopes. It does not discuss error handling or what happens with no results, but the output schema likely covers return structure. Overall sufficient for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters have schema descriptions (100% coverage), achieving baseline 3. The description adds value by explaining how parameters like query (case-insensitive substring) and time_filter (applied server-side) are used in the overall algorithm, and notes the max_spaces cap when space_id is omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Chat messages by text and/or time across one or many spaces. It specifies the client-side substring matching approach and explicitly distinguishes from the sibling tool get_messages for unfiltered single-space retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance to use get_messages for a single space without filtering. It also lists required OAuth scopes. However, it does not mention when to use alternative search tools like search_gmail_messages, though that is a different domain (Gmail vs Chat).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 write nature (OAuth scope) and the important behavior of overriding inherited master/layout backgrounds with a solid color. However, it does not mention reversibility, side effects on other slide properties, or error conditions, which would elevate it to a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences, each serving a distinct purpose. The first sentence is the action, second distinguishes from alternatives, third covers usage pattern and key behavior. No fluff, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers purpose, alternatives, usage pattern, OAuth scope, and key behavioral trait. It is complete enough for an agent to use correctly, but lacks error handling or edge case details that would make it a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the baseline is 3. The description does not add any parameter-specific semantics beyond what the schema already provides (e.g., for color, alpha, page_object_id). The `user_google_email` parameter lacks schema description and is not elaborated in the description, meaning the description adds no extra value for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Set the background fill color of a single slide' with the verb 'set' and resource 'background fill color'. It distinguishes from shape styling by noting it affects the page itself, not a shape, and explicitly names the sibling tool `style_slides_shape`. This provides high specificity and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides an alternative tool for shape fills (`style_slides_shape`) and instructs to call this tool once per slide for multiple slides. It also documents the required OAuth scope, giving clear when-to-use and what-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool handles both creation and update in one call, automatically creates if missing, and replaces existing content. It also advises that no prior creation is needed. While it doesn't cover permissions or error handling (e.g., invalid header/footer type), the key behavioral traits are well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two paragraphs with clear front-loading: first sentence immediately states the purpose. Each sentence adds value, no fluff. Structured with bullet-like emphasis using 'If...' clauses. Efficiently conveys all essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters (4 required) and presence of an output schema, the description covers the tool's core purpose and usage guidelines. It lacks details on error conditions (e.g., non-existent document) or parameter constraints (e.g., valid header_footer_type values), but for a straightforward tool, it provides sufficient context for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions. Baseline is 3. The description adds limited extra meaning beyond the schema: it explains that section_type is 'header' or 'footer' and that content is text, but these are already clear from schema. The description's main value is explaining how parameters relate to tool behavior (e.g., no need to create separately), which is more behavioral than parametric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's function: 'Safely creates or updates header/footer text in a Google Doc.' It specifies the verb (creates or updates), resource (header/footer text in a Google Doc), and distinguishes from sibling tool batch_update_doc by noting this is the 'default tool' for header/footer content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly tells the agent when to use this tool ('default tool for header/footer content') and when not to use alternatives ('Do NOT use batch_update_doc with create_header_footer just to set header/footer text'), naming the alternative and explaining why the low-level approach is inferior ('only for advanced section-break workflows and can fail').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It covers atomicity (single atomic batch), low-level nature, and includes caveats about index calculation errors and the workflow to avoid them. It does not explicitly state error handling or return values, but the presence of an output schema mitigates this. Overall, good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured with clear sections (RECOMMENDED WORKFLOW, PHASE 1, etc.). It front-loads the purpose and then provides detailed guidelines. Every sentence adds value, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (many operation types) and the presence of an output schema, the description is fairly complete. It covers main workflows, alternatives, and common pitfalls. It could include more on error handling or specific edge cases, but overall it's thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining the recommended use of end_of_segment, the purpose of tab_id and segment_id, and the overall workflow. It provides context that helps the agent use parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes multiple low-level document operations in a single atomic batch update. It specifies the verb (executes), resource (low-level document operations), and distinguishes from siblings by mentioning alternatives like update_doc_headers_footers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool and when to prefer alternatives. It says 'For normal header/footer text, prefer update_doc_headers_footers' and 'Only use create_header_footer here for advanced section-break layouts.' It also includes a recommended workflow for building documents in phases, which is highly actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses atomic execution with rollback on partial failure and OAuth scope requirement. It could mention potential destructiveness, but the core 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences that front-load purpose, then add context and behavioral details. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-level batch API, the description covers purpose, usage, atomicity, and authentication. The presence of an output schema likely covers return values, making this complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description does not add additional meaning beyond the schema, earning baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies a batch of Slides API edit requests atomically. It explicitly contrasts with high-level helpers, distinguishing it as the low-level escape hatch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (for operations not covered by high-level helpers) and notes atomicity and rollback behavior, providing clear guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it checks first match, requires drive.readonly scope, and is a helper for embedding. However, does not explicitly state output format or error behavior (e.g., if no file found). Still good for a simple tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured with main action first, then context and alternatives. Every sentence adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of an output schema, the description covers purpose, usage context, sibling differentiation, and OAuth requirement. It is self-contained and complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. Description adds context about filename search and multiple matches but does not elaborate on the email parameter. Sufficient overlap with schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Search' and 'report' with specific resource 'whether file is publicly linked'. Differentiates from sibling 'get_drive_file_permissions' for specific files. Aligns with Google Docs embedding use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (before insert_doc_image), limitation (checks first if multiple matches), and alternative for specific file (get_drive_file_permissions). Also mentions required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses side effects (creates new file owned by caller, preserves content/formatting) and required scope. Could be more specific about permission handling or limits, but sufficiently transparent for typical use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (three sentences) but packed with essential info: action, side effects, usage guidance, and scope. Front-loaded with verb and resource, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists (handles return values), description covers all key aspects: purpose, side effects, alternatives, and prerequisites. No gaps for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds minimal extra meaning beyond schema (e.g., default name pattern, parent folder default 'root'). No in-depth parameter elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Duplicate a Drive file'), specifies the resource (Drive file including Google Docs/Sheets/Slides), and distinguishes from sibling tool 'copy_drive_folder' by explicitly mentioning folder handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: for folders, use copy_drive_folder; for Google Docs, describes a standard pattern (copy then edit). Also mentions required OAuth scope, giving clear instructions for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the side effect ('appends a new tab at the end') and the OAuth requirement. However, it could also mention that the operation modifies the spreadsheet, which is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two targeted sentences plus a line about alternatives and auth. Every sentence adds value, no fluff, and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (3 required params, high schema coverage, output schema exists), the description covers purpose, side effects, auth, and alternatives sufficiently. No gaps remain for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a good description. The tool description does not add extra meaning beyond the schema, as the uniqueness constraint for sheet_name is already in the schema. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add a new tab (sheet) to an existing spreadsheet.' It uses a specific verb ('Add') and resource ('tab to spreadsheet'), effectively distinguishing from siblings like create_spreadsheet (new spreadsheet) and manage_sheet_tabs (rename/reorder/delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides alternatives: 'To rename/reorder/delete tabs use manage_sheet_tabs. For a brand-new spreadsheet use create_spreadsheet.' It also mentions the required OAuth scope, guiding proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses permanent removal, notes that UI undo works but no API undo, and states the required OAuth scope. This provides complete behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loaded with the primary action, and every sentence adds value. There is no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (not shown) and the tool is a destructive operation, the description covers side effects, prerequisites, and alternatives. It is complete for an agent to understand impact and requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all three parameters with descriptions (100% coverage). The description adds value by explaining the source of tab_id ('Get from list_doc_tabs or inspect_doc_structure'), but does not significantly expand beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a tab') and the resource ('and its entire sub-document from a Google Doc'). It distinguishes from the sibling tool 'update_doc_tab' by noting that renaming is an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance by stating when to use this tool (permanent delete) and offers an alternative: 'To just rename a tab use update_doc_tab.' It also mentions that there is no API undo, which helps set expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the required OAuth scope (contacts.readonly), implying a read-only operation. While it does not detail side effects (none expected), it adequately conveys the tool's safe, non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the core purpose. Every sentence adds value: purpose, usage context, alternative tool, and authentication requirement. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 need not detail return values. It covers purpose, usage, alternatives, and authentication. For a simple fetch tool, the description is fully complete and leaves no ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds no new parameter information beyond what the schema provides, resulting in minimal added value. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Fetch a single contact with all details,' using a specific verb and resource. It lists included data fields (emails, phones, orgs, addresses) and distinguishes from sibling tools like list_contacts (which returns summaries) and manage_contact (for create/update).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use this when you already have a contact ID from list_contacts or search_contacts and need the full record.' It also directs to manage_contact for creating/updating, providing clear when-to-use and when-not-to instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions 'requires the drive.readonly OAuth scope', implying read-only behavior. Could add more detail about what data is returned, but output schema exists. Good overall.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with purpose: states action, provides usage guidance with alternatives, and lists scope requirement. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and complete parameter descriptions, the description adds appropriate context: purpose, usage scenario, alternatives, and auth requirement. Fully sufficient for an agent to understand when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter names and descriptions. Description does not add new parameter details but reinforces usage context (file_id from search_drive_files or shareable URL). Meets baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it 'inspects' permissions and public-link status of a Drive file. Distinguishes from siblings like set_drive_file_permissions and check_drive_file_public_access by explicitly naming them for alternative actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to audit who can access a file before sharing externally.' Provides clear alternatives: set_drive_file_permissions or manage_drive_access for changing, check_drive_file_public_access for quick check. Also mentions required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States 'Read-only — does NOT change sharing' to clarify non-destructiveness, and mentions required OAuth scope. Lacks details about error handling or response structure, but output schema may cover that. Still good transparency for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adds distinct value: purpose, behavior with alternatives, and required scope. No filler, properly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity (2 params, output schema, no enums), the description covers purpose, behavior, alternatives, and scope. Additional details on return format are not needed due to output schema. Complete for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully described in schema. The description adds no additional semantics beyond what the schema already provides. Hence baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Fetch the webViewLink and current permissions for a Drive item.' Identifies specific resource and verb, and distinguishes from sibling tools like manage_drive_access and get_drive_file_permissions by stating it is read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Read-only — does NOT change sharing. To modify sharing use manage_drive_access. For a fuller permissions audit use get_drive_file_permissions. Requires the drive.readonly OAuth scope.' Provides clear when-to-use and when-not-to-use guidance with alternatives and prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It explains that the returned item indices and IDs are handles for updates, and that it requires read-only OAuth scope. It implies a read-only operation, and does not mention any destructive side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise paragraphs, each with a distinct purpose: stating functionality, usage guidance with sibling differentiation, and authorization requirement. No redundant or filler sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only fetch tool with an existing output schema, the description fully explains purpose, usage context, and prerequisites. It also distinguishes from sibling tools for response data, making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions. The description adds helpful real-world context (e.g., form_id is the string after /forms/d/ in the URL, supports both user-owned and shared forms), supplementing the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'fetch', the resource 'Google Form', and the scope 'metadata and full item list'. It distinguishes from sibling tools (list_form_responses, get_form_response) by specifying that this tool is for form structure, not response data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this tool before batch_update_form and distinguishes from response data tools. Mentions required OAuth scope, but does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies read-only behavior via the word 'Retrieve' and discloses the OAuth scope requirement. However, it does not explicitly state that no data is modified or list any side effects, which 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a clear purpose: purpose statement, usage guidelines with alternatives, and scope requirement. No redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered elsewhere. The description covers purpose, usage, and authentication requirements. It is complete for an agent to decide whether to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal meaning beyond the schema (e.g., hinting that thread_id comes from search). No further parameter details are needed given complete schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and resource ('every message in one Gmail conversation thread'). It clearly distinguishes itself from siblings by naming get_gmail_message_content for single messages and get_gmail_threads_content_batch for multiple threads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (need whole back-and-forth), when not to use it (single standalone message), and provides specific alternative tool names. It also mentions the required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It reveals that the tool is read-only (requires presentations.readonly scope), returns a URL not image bytes, and that the URL is short-lived. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences. First sentence states purpose, second gives usage guidance and return type, third explains URL behavior and scope. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema in the input, the description effectively explains what is returned (a Google-hosted URL) and its ephemeral nature. It also covers the OAuth scope and alternative tool. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond the schema for parameters. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Generate a PNG thumbnail URL for one slide', which is a specific verb+resource combination. It distinguishes from sibling 'get_page' by noting 'For slide element details use get_page', making the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use ('Useful for visual previews') and when not to ('For slide element details use get_page'). It also advises to fetch and cache quickly due to short-lived URLs, and mentions the required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description indicates read-only behavior via 'presentations.readonly OAuth scope.' Details that it returns slide objectIds needed by other tools, providing helpful behavioral context without contradicting any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences with no unnecessary words. Each sentence adds value: purpose, return value relationship to other tools, and scope requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description adequately covers context: read-only scope, return information linking to other tools, and alternative tools for specific needs. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions; the description adds no additional semantic detail beyond what's already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'retrieve' and 'extract' with specific resource 'presentation's structure and text per slide.' Distinguishes from sibling tools like get_page and get_page_thumbnail by specifying its broader scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool vs alternatives: 'For a single-slide deep dive use get_page. For a rendered thumbnail image use get_page_thumbnail.' Also mentions required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description indicates a read operation via 'Retrieve' and the required 'script.projects readonly OAuth scope', but does not explicitly state it makes no changes. Adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant information. Very concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Prerequisites, usage advice, OAuth scope, and output schema (implied) are covered. Complete for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds context about using after get_script_project but does not enhance parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full source of one file in an Apps Script project. It distinguishes from sibling tools like get_script_project (overview) and update_script_content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this after get_script_project for file names, and mentions get_script_project as an alternative for project-wide overview. Also specifies the required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the read-only nature via OAuth scope, time series granularity (7 days/8 weeks), and required permissions. However, it lacks details on pagination or rate limits, which are absent but not critical given the output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding unique value: main action, time range and granularity, usage context and alternative. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and complete schema descriptions, the description covers purpose, usage, alternative, and required scope. It is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add extra semantics beyond the schema descriptions for the parameters. It does not explain default behavior or constraints further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Fetch', resource 'execution analytics for a script', and specific metrics (users, runs, failures). It distinguishes itself from sibling 'list_script_processes' by contrasting per-execution details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('adoption audits and error monitoring') and provides an alternative ('For per-execution details use list_script_processes'). This gives clear guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool retrieves metadata and all file contents with a 200-char preview, implying a read-only operation. It mentions readonly OAuth scope. While it doesn't explicitly state no side effects, the 'Retrieve' verb and scope make it clear. Slight omission of explicit non-modification statement prevents a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: first sentence states purpose, second adds detail on output, third gives alternatives and scope. It is front-loaded, concise, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which likely details metadata fields and file content format), the description's mention of 'metadata and all file contents' with a preview length is sufficient. It also includes required OAuth scope. For a read-only tool with two straightforward parameters, the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, so baseline is 3. The description adds value by contextualizing script_id usage ('from list_script_projects or a script URL'), which goes beyond the schema description. This enhances understanding of how to obtain the parameter value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve an Apps Script project's metadata and all file contents' with specific verb and resource. It distinguishes from sibling tools get_script_content and update_script_content by noting the 200-char preview and directing to alternatives for full content or writing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs to get_script_content for full file content and update_script_content for writing, providing clear context for when to use this tool vs alternatives. It also mentions required OAuth scope. It lacks explicit 'when not to use' guidance, but the alternatives are well stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return value scope ('list-level info only, title, last updated') and required permissions (OAuth scope). Does not detail potential errors or idempotency, but for a simple read operation, this is sufficient and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, efficient with no redundant words. Each sentence adds value: purpose, return info with alternative, and authentication requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists (not shown), description need not detail return structure. Covers input expectations (requires list ID from list_task_lists), contrasts with sibling, and explains scope. Complete for a simple metadata fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions already clear. Description does not add extra parameter meaning beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Fetch metadata' with specific resource 'single Google Tasks task list'. Distinguishes from sibling 'list_tasks' by stating that for tasks, use that alternative. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (get list metadata) and when not to (use list_tasks for tasks). Mentions required OAuth scope (tasks.readonly), which is a key prerequisite. Provides clear guidance for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the automatic index bump from 0 to 1 and the OAuth scope requirement. No annotations present, so description bears full burden. Could mention error handling or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured, and front-loaded with the main purpose. Every sentence adds value without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters with full schema coverage and an output schema, the description covers purpose, usage alternatives, and a key behavioral detail (index bump). No gaps for an insertion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description repeats some schema info (e.g., rows/columns for table) but adds value with the index bump note. No additional semantic detail beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (insert) and resources (table, list, page break into a Google Doc). Distinguishes from sibling tools like modify_doc_text, insert_doc_image, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use this tool versus alternatives for plain text, images, and file chips. Also notes the index bump behavior and required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects (creates empty tab), context about Google Docs tabs (Oct 2024), and scope requirement. No annotations provided, so description carries full burden; lacks detail on rate limits or reversibility but sufficient for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose, then side effects and alternatives. Five sentences with no fluff, each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description doesn't need to explain return values. Covers side effects, scope, and usage context. Complete for a create tool with well-documented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 5 parameters with descriptions. The description adds context about parent_tab_id for nesting and index for positioning, but this is already in schema. Baseline score of 3 appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a new tab in a multi-tab Google Doc.' Distinguishes from sibling tools list_doc_tabs, update_doc_tab, and delete_doc_tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists when to use alternatives: 'To list existing tabs + IDs use list_doc_tabs; to rename use update_doc_tab; to delete use delete_doc_tab.' Also mentions required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 required OAuth scope ('script.deployments.readonly'), indicating a read-only operation. However, it does not mention potential pagination or error handling for invalid script IDs, which are minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each serving a distinct purpose: main action, definition, sibling guidance, and auth requirement. No fluff, well-structured, and front-loaded with the key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 and clear parameters, the description covers the purpose, the concept of deployments, sibling differentiation, and auth. No missing elements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds no additional meaning beyond the schema, so it's at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all deployments (versioned snapshots) of an Apps Script project,' providing a specific verb and resource. It distinguishes itself from sibling tools by mentioning 'manage_deployment' for management and 'list_versions' for code versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs when to use this tool vs alternatives: 'For managing deployments use manage_deployment; for code versions use list_versions.' This provides clear usage context and avoids confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description provides good behavioral context: read-only operation (drive.readonly scope), lists direct children, and shared drive behavior. It could mention pagination implicitly but parameters cover it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four concise sentences, front-loaded with core purpose, followed by usage guidance, scope clarification, and authentication. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 1 required), the description covers use case, alternatives, scope, and authentication. Output schema exists, so return values need not be described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds high-level context (folder_id as main parameter, drive_id interaction) but mostly repeats schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb "List" and the resource "files in one Drive folder (children of folder_id)". It distinguishes from sibling tool "search_drive_files" and specifies the scope (direct children) and shared drive interpretation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (browse by folder) and when to use the alternative (search_drive_files for content-based search). It also covers scope and OAuth scope requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses that it lists all labels, splits them by type, and requires readonly scope. It doesn't address pagination or rate limits, but for a simple list operation with output schema present, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence states purpose, second gives usage context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and an output schema, the description fully covers purpose, usage context, and prerequisites. No additional details needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (user_google_email) with 100% schema coverage. Description adds no extra semantics beyond schema; baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it 'list every label in the user's mailbox, split system vs user.' This is a specific verb+resource pair, distinguishing it from sibling tools like manage_gmail_label which modify labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states use case: 'Use this to discover label IDs before calling modify_gmail_message_labels / batch_modify_gmail_message_labels / manage_gmail_filter — label IDs (not names) are what those tools require.' Also notes required OAuth scope, providing clear guidance on when to apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses sorting order, required OAuth scope (drive.readonly), and that the returned ID feeds other tools. It does not detail pagination or exact output, but an output schema exists. It could be more explicit about 'accessible' meaning spreadsheets the user has access to, but overall 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the key purpose and ordering, then use case, alternative, and scope. Every sentence adds value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two parameters and an output schema, the description is complete. It covers purpose, usage guidelines, behavioral traits (ordering, scope), and provides an alternative. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are described in the schema. The description adds no additional information about the parameters beyond what the schema provides. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List accessible Google Sheets spreadsheets' with ordering 'most-recently-modified first', clearly specifying the verb and resource. It distinguishes from the sibling tool search_drive_files by mentioning that for a broader search by name, the sibling should be used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this as a discovery step when the user only has a spreadsheet name', providing when to use the tool. It also gives an alternative: 'For a broader Drive search by name use search_drive_files with file_type="sheet"', offering clear when-not and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the required read-only scope ('Requires the tasks.readonly OAuth scope') and implies the operation is safe. However, does not mention pagination behavior beyond schema fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each adding value: purpose, usage flow, sibling differentiation, and auth requirement. Front-loaded with the action. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of an output schema, this description covers all necessary context: what it does, why to use it, alternatives, and auth. Completes the picture for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline is 3. Description adds context for output but does not enhance parameter meanings beyond the schema descriptions. The mention of 'discover task_list_id' hints at output but not parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List the user's Google Tasks task lists' with a specific verb and resource. It distinguishes from siblings by mentioning 'list_tasks' and 'manage_task_list', 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to discover task_list_id before calling list_tasks, get_task, or manage_task' and 'For modifying task lists themselves use manage_task_list', providing clear when-to-use and when-not-to guidance. Also mentions required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description bears full burden. It explains versions are immutable snapshots, requires readonly scope, and mentions automatic or manual creation. Does not detail pagination or order, but adequate for a read-only list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose. Every sentence provides value: definition, relationship to deployments, sibling reference, and authorization. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, return values are covered. Description explains version concepts, creation methods, and scope. Complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, so baseline is 3. Description does not add extra parameter-level meaning beyond scope info. No improvement over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists all versions of an Apps Script project, with specific verb and resource. Differentiates from sibling list_deployments by explaining versions are snapshots referenced by deployments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool (to list versions) and when to use alternatives (list_deployments for deployments). Also mentions the required readonly OAuth scope, aiding correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: auto-declines conflicting invitations, sets Chat to Do Not Disturb by default, lives on primary calendar only, and requires 'calendar.events' scope. This is good but lacks details on error handling or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but concise, covering purpose, usage alternatives, behaviors, and scope. It is front-loaded with the verb and resource. Slightly long but every sentence is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 16 parameters and high complexity, the description combined with the schema provides sufficient context for selection and invocation: what it does, side effects, usage guidelines, and a required scope. It could mention output schema or error scenarios but is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the Focus Time concept and side effects (auto-decline, Chat DND), which gives semantic context beyond parameter descriptions. This lifts the score to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates, lists, updates, or deletes Focus Time events, a specific event type. It distinguishes from siblings 'manage_event' and 'manage_out_of_office' by explicitly naming them and specifying what each handles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool (for Focus Time events) and when to use alternatives (manage_event for regular events, manage_out_of_office for OOO). It also notes side effects and OAuth scope requirements, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses side effects (creates/mutates/deletes a label) and notes that delete is destructive and unrecoverable. It also mentions the OAuth scope. With no annotations provided, this is good but lacks details on edge cases like duplicate names or invalid label IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences. The first sentence states the purpose, followed by side effects, alternative tool, and auth requirement. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool manages CRUD on labels with explicit side effects and alternative guidance, plus the schema covers all parameters, the description provides sufficient context for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description does not add new parameter details beyond what the schema provides (e.g., it doesn't elaborate on the meaning of label_list_visibility or message_list_visibility).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates, updates, or deletes a Gmail label, specifying the resource (label) and actions. It differentiates from the sibling tool modify_gmail_message_labels by noting that tool handles applying/removing labels from messages, not managing labels themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance, including when not to use (for message label changes) and directs to an alternative tool (modify_gmail_message_labels). It also states the required OAuth scope (gmail.labels).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses required OAuth scope, the two enforcement modes, limitation about bypassing, and that it's a UI-level protection. Missing potential error handling or permissions details, but covers key traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-organized paragraphs: purpose/modes, usage advice, scope and limitations. No fluff, every sentence adds value. Front-loaded with core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description does not need return details. It covers purpose, modes, limitations, and scope adequately for a protection tool. No gaps observed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83%, and description adds meaningful context for parameters: explains warning_only behavior, range name examples, editor_emails access requirement. Only user_google_email lacks added context. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'protect a range' and resource 'spreadsheet', specifies it adds a 'Protected range' entry, and distinguishes from sibling tools like manage_sheet_tabs (sheet-level) and format_sheet_range (formatting).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for using strict vs warning-only modes, and warns that protection does not block owners/editors via UI, recommending Drive sharing for hard control. Lacks explicit when-not-to-use but offers clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses important behavioral traits: uses People API searchContacts endpoint, max 30 results, cache warm-up on first use due to lazily populated search index, and required OAuth scope (contacts.readonly). While it doesn't detail edge cases or error behavior, the provided context is substantial and adds 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and well-structured: first sentence states purpose, second gives API details, third provides usage guidelines, fourth mentions cache and auth. Every sentence adds value, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 params, no annotations, but an output schema exists), the description covers behavioral traits, usage guidelines, and auth requirements adequately. It does not need to explain return values due to the output schema. The description is complete enough for an agent to decide when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter descriptions. The tool description does not add significant new meaning to the parameters beyond summarizing the query functionality. However, it adds context like cache warm-up and OAuth scope, which are not parameter-specific. Thus, score is at baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the resource 'contacts', specifying the search across names, emails, and phones. It distinguishes from siblings 'list_contacts' (full enumeration) and 'get_contact' (by ID), providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use alternatives: 'For paginated full enumeration use list_contacts. For a known contact ID use get_contact.' This provides clear when-to-use and when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses the required OAuth scope (gmail.readonly) and explicitly states the tool returns only IDs and links, not bodies. This adds value beyond the schema, though pagination behavior is left to schema parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value. Front-loaded with purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers OAuth scope, return type, workflow, and alternatives. Given the output schema exists, further detail on return values is unnecessary. Complete for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description does not need to add much. The description itself does not elaborate on parameters beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it searches Gmail messages and returns IDs plus clickable links. It distinguishes from siblings like get_gmail_message_content and get_gmail_messages_content_batch by specifying that this tool returns only IDs, not bodies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (before fetching bodies) and names alternatives (get_gmail_message_content for single, get_gmail_messages_content_batch for many). Also clarifies the two-step process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes side effect: 'creates a new visible message in the space.' Mentions required OAuth scope. Lacks discussion of rate limits or other constraints, but still provides strong behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: three short sentences with clear front-loading. Every sentence adds value (purpose, side effects, alternatives, scope). No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, no need to describe return values. Description covers purpose, side effects, threading, required scope, and alternatives. Complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. Description adds minimal parameter-specific detail beyond schema; it mentions threading and markdown but those are already in schema. Baseline 3 due to high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Post a text message to a Google Chat space (optionally threaded).' Uses specific verb 'post' and resource 'text message'. Distinguishes from siblings by explicitly naming alternative tools for reactions and listing messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use this tool vs alternatives: 'For adding an emoji reaction... use create_reaction. For listing... use get_messages.' Also mentions required OAuth scope and side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'Side effects: mutates sharing policy' and the required OAuth scope. However, it doesn't discuss potential reversibility, rate limits, or error conditions, which would add completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with 5 sentences that are well-structured and front-loaded with the main purpose. Every sentence adds value without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so description doesn't need to explain return values) and the schema covers all parameters, the description provides sufficient context: purpose, side effects, usage guidance, and OAuth requirement. It is complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description summarizes the three toggle flags (link_sharing, writers_can_share, copy_requires_writer_permission) but does not add significant new meaning beyond what the schema already provides for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Toggle' and the resource 'link-sharing and common file-level sharing controls'. It distinguishes itself from the sibling 'manage_drive_access' by specifying that this tool is for high-level toggles while the sibling is for per-user/group changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (high-level toggles) and when not to (use manage_drive_access for per-user/group changes). Also states 'At least one of the three flags must be set' and the required OAuth scope, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes side effects: mutates publish settings, changes discoverability and authentication requirements. States non-effects. No annotations provided, so description carries full burden. Lacks details on return values or potential failures, but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose, side effects, exclusions, and requirements. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (4 params, 2 required, output schema exists), description covers purpose, side effects, non-effects, alternative, and auth requirement. Complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds context about the role of parameters (template, auth) but does not provide additional semantic meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Update a Google Form's publishing and auth requirements.' Specific verb+resource, distinguishes from sibling batch_update_form which changes items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states what it does and what it does not do, and provides an alternative: 'Does NOT change which items are on the form; for that use batch_update_form.' Also mentions required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the OAuth write requirement, the partial-update behavior (only passed fields changed), and implicitly that it modifies the presentation. However, it does not mention the response structure (error handling, success status) or explicitly state that the shape must exist. The parameter-level note that table cells and images will error is helpful but in param description, not main. Overall, it's transparent but could add a note on return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences for purpose and alternatives, plus a third for auth and update behavior. It front-loads the core action, wastes no words, and every sentence earns its place. Ideal length for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (3 required), high schema coverage, and presence of an output schema, the description covers all essential aspects: purpose, differentiation from siblings, auth requirements, and update semantics. It leaves no major gaps for an AI agent to understand when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 88%, so the schema already provides detailed meaning for most parameters. The main description only summarizes the categories (fill color/opacity, outline color/thickness/dash). It does not add new semantics beyond the schema, hence baseline 3. No parameter semantics improvement from the description itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'style' and the resource 'existing shape's fill and outline'. It explicitly distinguishes from sibling tools: format_slides_paragraph for paragraph text, format_slides_text for character styling, and create_slides_shape for creation. This leaves no ambiguity about the tool's core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: use for styling existing shapes, not for text formatting or creation. It lists the specific alternatives and conditions, such as requiring write OAuth scope and that only passed fields are updated. This fully informs 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical side effect: 'any file NOT included in files is deleted.' Also mentions required OAuth scope. With no annotations provided, the description fully carries the behavioral transparency burden and does so excellently.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no fluff. First sentence states purpose, second warns of side effect, third gives usage guidance. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, side effect, prerequisite action, auth requirement. With an output schema present for return value details, the description is complete for a mutation tool of moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The schema itself already describes parameters in detail (e.g., files array structure). Description adds no extra parameter-specific meaning beyond behavioral context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Write files into an Apps Script project (replacing the full set)'. Specific verb (write), resource (Apps Script project), and key differentiator (full replace). Distinguishes from sibling tools like get_script_content or run_script_function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'Always fetch via get_script_project first, modify the set, and pass the complete list back.' Provides a clear prerequisite and workflow. Missing explicit 'when not to use', but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses side effects ('creates a reaction visible to everyone'), limitations (Unicode only), and auth requirements. Could be more detailed about idempotency or response, but covers key behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each serving a purpose: action, side effects, limitations/alternative, auth. No redundant information, efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, the description covers purpose, usage guidelines, side effects, and limitations. An output schema exists, so return value details are not needed. The description is thorough enough for a typical create tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by clarifying that 'emoji_unicode' must be a Unicode character and that custom emoji are not supported. This extra context helps the agent avoid invalid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add an emoji reaction to a Chat message' with a specific verb and resource. It distinguishes from sibling tools like 'send_message' by noting that it is for reactions, not posting new messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when not to use it (Custom Workspace emoji not supported), provides an alternative ('For posting a new message use send_message'), and specifies the required OAuth scope ('Requires the chat_write OAuth scope').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral aspects: it explains what the tool shows (dimensions, positions, content, insertion indices) and how to interpret the output, leaving no ambiguity about its non-destructive, read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headings and bullet points, making it easy to scan. While slightly verbose, it front-loads key information and each section adds value, earning a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is fully complete for a debugging tool: it covers when to use, what to expect, how to read output, and integrates into workflow. Presence of output schema further ensures no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add significant new meaning beyond the schema's parameter descriptions. The baseline of 3 is appropriate because the schema already provides clear definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a debugging utility for tables, listing specific error scenarios and use cases. It distinguishes itself from sibling tools by being diagnostic rather than manipulative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool (immediately on table issues, after creation, before population, after failure) and references a sibling tool (populate_existing_table) for workflow context, providing clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description covers key behaviors: exact copy, insertion position, return of new ID, and required OAuth scope. Lacks mention of potential side effects like auto-save, but generally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient 8-sentence structure, front-loaded with main purpose, each sentence adds distinct value. No redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core functionality, limitations, chaining, alternatives, and auth. Lacks error handling details, but overall sufficient for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema: explains page_object_id can be slide or element with examples, and clarifies cloning behavior. Schema has 67% coverage; description fills gaps for the undocumented parameter and adds context for others.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states duplicate slide or page element within a presentation, specific verb and resource. Distinguishes from siblings like copy_drive_file and mentions chaining with reorder_slides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (exact copy, same presentation), when not to (different presentation), and provides alternatives. Also notes limitation of one object per call and loop for many.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 side effect of creating a new PDF file while leaving the original Doc untouched. It also mentions required scopes. However, it could mention rate limits or specific error conditions for non-native Docs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three focused sentences: first states the core function, second covers side effects and alternatives, third lists requirements. No extraneous words, front-loaded with main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 need not detail return values. It adequately covers side effects, usage alternatives, and scopes. However, it might mention that the tool will fail if the document_id is not a native Doc, which is implied but not explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by noting that pdf_filename auto-appends '.pdf' and folder_id defaults to My Drive root. It also clarifies that document_id must be a native Doc, enriching the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary action: 'Export a Google Doc as PDF and save the PDF back into Drive.' It specifies the verb (export), resource (Google Doc), and outcome (save to Drive), distinguishing it from siblings that download bytes without saving.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-not-to-use guidance by directing to 'get_drive_file_download_url with export_format="pdf"' for downloading without saving, and for other export formats. Also mentions required OAuth scopes, which helps the agent understand prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: extraction details for each file type, fallback for scanned PDFs, and OAuth scope requirement. It is transparent about what the tool does without contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, but the second paragraph is somewhat dense. It efficiently conveys extraction behavior without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers all necessary aspects: extraction logic, fallbacks, OAuth requirement, and shared drive support. It is complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The tool description does not add extra semantics beyond the schema (e.g., does not redefine or elaborate on parameters), so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Download a Drive file and return its text (auto-extracting per type)', specifying the verb and resource. It distinguishes from sibling tools like get_drive_file_download_url and get_file_metadata by contrasting use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use this tool ('Use this when you need file text') and provides alternatives for URL and metadata. Also mentions handling shared drives, giving clear guidance on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains mode behavior, parameter interactions (event_id overrides range), defaults, and filtering. Slightly missing details on pagination or error handling, but largely transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) with clear structure: mode breakdown, sibling tool references, and auth note. No filler words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of output schema, return values need not be detailed. The description covers modes, parameters, filtering, and auth. Minor omission: no mention of pagination or error states, but it's sufficient for a read tool with good schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the two modes and how event_id overrides range/query params, and clarifies time_min default and max_results cap. This goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches calendar events by ID or filtered range, specifying two modes. It distinguishes itself from siblings like query_freebusy and manage_event, providing a precise verb+resource+scope definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly details when to use each mode (event_id vs. time window), mentions alternatives (query_freebusy for free/busy, manage_event for create/update), and lists required OAuth scope. Clear guidance for agent selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses the OAuth scope requirement, implying read-only access (scope is readonly). While it doesn't explicitly state 'read-only' or 'no side effects', the scope and fetch operation imply non-destructiveness. Could be more explicit but still adds useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three short paragraphs. First sentence states purpose, second provides usage guidance and alternatives, third lists OAuth scope. No filler, every sentence earns its place. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return value documentation is handled. Description covers usage context, alternatives, and auth requirements. It does not address error handling (e.g., invalid responseId) but for a simple fetch tool this is acceptable. Slightly incomplete but sufficient for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, all parameters have descriptions. Description adds meaning by explaining response_id as 'opaque string not the same as row number' and links to list_form_responses for source. It also explains the output structure ('keyed by question ID') and how to map questionId via get_form, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fetch a single submitted response to a Google Form, including all answers keyed by question ID', which specifies verb and resource. It distinguishes from sibling tools by explicitly mentioning when to use 'list_form_responses' for bulk listing and 'get_form' for question ID mapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says 'Use this when you already know the specific responseId' and provides alternatives: 'For bulk listing... use list_form_responses' and 'To look up which questionId maps to which question prompt, call get_form'. Clear guidance on when and when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature via the required OAuth scope (presentations.readonly) and specifies the data returned. No annotations to supplement, but the description covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is four sentences, front-loaded with the action, then usage guidance. No unnecessary words, but could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately explains the return content (element list, types, layout) and authentication requirement. No missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameter descriptions. The description adds value by linking page_object_id to get_presentation's output format, which helps the agent construct the correct input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch one slide's element list, types, and layout') and distinguishes from sibling tools like get_page_thumbnail and get_slides_speaker_notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (after get_presentation for slide details), and provides alternatives for thumbnails and speaker notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses conversion behavior (preserves formatting), server-side processing, and required OAuth scope. Lacks details on file disposition (original file kept/deleted) but covers key behavioral traits beyond annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with main purpose. Every sentence adds value: conversion description, use case guidance, sibling differentiation, and scope requirement. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, 100% schema coverage, and an output schema, the description covers purpose, usage, and key behaviors. It does not detail return values (handled by output schema) but provides sufficient context for a conversion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by noting mutual exclusivity of content/file_path/file_url (though already in schema) and providing safety context for file_path ('Path safety validated') and file_url ('SSRF-protected with size limits').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Convert a source file into a native Google Doc on upload' with specific verb and resource. It differentiates from sibling tools like create_drive_file and insert_doc_markdown/insert_doc_elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use this (not create_drive_file) when you want a real Google Doc editable in the web UI. For adding content to an existing Doc use insert_doc_markdown or insert_doc_elements.' Clearly states when and when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description covers auto-wrapping, query limitations in shared drives (owner-based queries fail), workaround using modifiedTime, and parameter behaviors like pagination and file_type aliases. Implicitly read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet comprehensive; each sentence adds new information. Structured with purpose, query types, alternatives, and OAuth scope. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (10 params, broad use), description covers purpose, differentiation, parameter details, limitations, and OAuth. Output schema handles return values, so completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant value: explains query wrapping, file_type alias resolution, order_by format with examples, corpora performance, and drive_id restriction. Goes well beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Search Drive (including shared drives) for files and folders.' Distinguishes from sibling tools like list_drive_items (for listing a folder by parent) and get_drive_file_content (for file content), providing specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains free-text vs. structured queries and offers alternatives (list_drive_items for parent listing, get_drive_file_content for content). Also mentions required OAuth scope and performance suggestions for corpora. Lacks explicit 'when not to use' but provides sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses atomicity (partial failure rolls back entire batch), requires forms OAuth scope, and implies destructive nature (modification). No annotations are provided, so the description carries the full burden. It could be improved by noting idempotency or rate limits, but it is adequate and accurate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact paragraphs with no wasted words. The first sentence captures the core purpose. Details are organized logically: atomicity, usage order, alternatives, and auth scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of batch update (multiple request types, atomicity) and the presence of an output schema, the description covers all essential behavioral and contextual aspects: what it does, prerequisites, alternatives, scope requirements, and atomicity behavior. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that each request object must have exactly one key (createItem, updateItem, etc.) and provides a link to full schemas. It also clarifies form_id source (edit URL) and user_google_email (authenticated account), going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it applies a batch of Forms API edit requests atomically, listing specific operations (add/update/delete questions, reorder, update info, toggle quiz mode). It distinguishes itself from sibling tools like set_publish_settings and get_form by positioning itself as the primary way to modify a form after creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use get_form first to discover existing itemIds/questionIds, and for publish settings to use set_publish_settings. This provides clear when-to-use and when-not-to-use guidance, with specific alternatives named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description details permanence, Drive API usage, no API undo, web UI restore possibility, and OAuth scope. Thorough for a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with purpose, then side effects, alternatives, requirements. Every sentence adds value, no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and schema coverage is high, description covers key behavioral aspects: permanence, side effects, restore path, alternative, auth scope. Complete for decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add extra meaning beyond schema descriptions; it mentions the authenticated account and script ID implicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Permanently delete an Apps Script project' with specific verb and resource. It distinguishes from sibling like manage_deployment for disabling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (permanent deletion), when not (use manage_deployment for disabling), and provides OAuth scope requirement. Clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: permanence of deletion, use of Slides UI undo for recovery, non-idempotent nature ('re-calling with the same ID after success returns an error'), and required OAuth scope. No annotations provided, so the description carries full burden and does so thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (~100 words), front-loaded with the core action, followed by usage details, requirements, and warnings. Every sentence adds meaningful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: what it does, what it works on, permanence, idempotency, recovery options, and scope requirement. Existence of an output schema (not shown) likely complements return value information, but description itself is self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 2 of 3 parameters with descriptions (presentation_id, object_id). The description adds value by explaining how to obtain object IDs from get_presentation or creator tools. However, user_google_email parameter is not described in either the schema or the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Delete any object from a Google Slides presentation by its object ID', clearly enumerating supported object types (slide, shape, text box, etc.). Distinct from sibling tools like duplicate_slide or batch_update_presentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on what can be deleted and the effect of different object IDs, and includes a limitation ('Cannot delete master/layout pages'). However, it does not explicitly discuss when to use this tool versus alternatives like batch_update_presentation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Details side effects across modes (stdio writes file, HTTP publishes URL, stateless returns base64 preview) with no annotations provided, fulfilling the behavioral disclosure burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences, front-loaded with purpose, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, description covers prerequisites, side effects, and auth scope comprehensively, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds context like message_id format and attachment_index default, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'download' and the resource 'Chat message attachment', distinguishing it from sibling tools like get_messages and other file download tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions using get_messages to discover message ID and attachment index, and the required OAuth scope. No explicit when-not-to-use but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes internal behavior: walks presentation, collects text elements, issues one updateTextStyle per element in a single batchUpdate. No annotations exist, so description fully carries the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each valuable: purpose, internal mechanics, sibling differentiation, auth requirement. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers batch behavior, sibling alternatives, OAuth scope. Output schema exists, so return values are documented. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so baseline 3. Description does not add additional parameter meaning, but not required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool bulk-applies character formatting to every text element on a slide or deck, distinguishing it from siblings format_slides_text and format_slides_paragraph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use this tool vs alternatives: for a specific element use format_slides_text, for paragraph-level rules use format_slides_paragraph. Also mentions required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses read operation and required scope. No mention of rate limits or side effects, but not needed for simple read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences: purpose, usage, requirements. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema separate, description covers purpose, usage, sibling tools, and requirements comprehensively for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage; description adds context on using member IDs with get_contact, reinforcing parameter use without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states fetching contact group details and member IDs. Distinguishes from sibling tools get_contact and manage_contact_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use get_contact for full records and manage_contact_group for membership changes. Also specifies required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it walks the document body, finds person and richLink elements, returns type/character range/key properties, requires OAuth scope, is read-only, safe to call repeatedly, and explains limitations (no headers/footers, only rendered chips). No contradictions with annotations (none).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it starts with a clear purpose, then details extracted elements, limitations, auth, and a scope note. Each sentence adds value without redundancy. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (implied), the description covers all necessary context: what is extracted, scope restrictions, auth requirements, and important notes about rendering. It is complete for an agent to decide when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only document_id has a description). The description does not add meaning for the user_google_email parameter beyond its name, which is fairly self-explanatory. However, the description adds value to the overall tool behavior, not the parameters. Given moderate coverage and clear parameter names, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'extract' and the resource 'smart chips' with specific types (person mentions and rich links). It distinguishes from sibling tools like insert_doc_person_chip and insert_doc_file_chip by noting that programmatically inserted chips are not included, and contrasts with inline hyperlinks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists use cases (auditing @mentions, validating links, building chip inventory) and explicitly states what it does NOT include, providing alternatives (direct text scan for hyperlinks, user opening doc in UI for programmatic chips). This gives clear guidance on when to use this tool versus other methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully covers behavioral traits: writes to storage or exposes a time-limited URL, exports Google-native files with specific formats, requires drive.readonly scope, and has side effects. It is transparent and does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with front-loaded action, followed by side effects, comparison to sibling, export details, and auth requirement. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers purpose, usage guidelines, side effects, auth requirements, export behavior, and differentiation from a sibling tool. It is complete for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% and includes detailed descriptions for all parameters (user_google_email, file_id, export_format). The description adds context about export behavior but does not provide new parameter-specific dimensions beyond the schema, so a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves a Drive file to disk or exposes a temporary URL, distinctly differentiating it from get_drive_file_content by noting it handles binary files and exports. The verb 'Save' and resource 'Drive file' are specific, and the differentiation from a sibling tool is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly directs to use get_drive_file_content for text content and advises using this tool when needing binary files or exports. It also describes behavior in stdio vs HTTP modes and export formats, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses internal chunking, fallback behavior, format options, and auth scope. While not exhaustive (e.g., rate limits, error handling beyond fallback), it provides sufficient transparency for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences: first states core action, second provides usage guidance and internal details, third adds format recommendation and auth requirement. No unnecessary words, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not detail return values. It covers batch behavior, alternatives, format nuances, and auth requirement, making it complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers parameters 100% with descriptions. The description adds value by clarifying message_ids has no hard cap (auto-chunked), format='metadata' is faster for triage, and body_format applies only when format='full'. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches many Gmail messages in batch, internally chunked. It distinguishes itself from the sibling tool get_gmail_message_content by recommending this batch approach, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to prefer this over a loop of get_gmail_message_content, explains the batch API chunking (25 per request) and fallback to sequential fetches, and recommends using format='metadata' for headers-only triage. Also specifies the required OAuth scope, providing comprehensive usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It discloses the required OAuth scope (spreadsheets.readonly), states that it surfaces conditional format counts per tab, and explicitly states it does not read cell values. This covers safety and behavioral traits beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, well-structured, and front-loaded with the core purpose. It then provides usage guidance and a clarifying note. Every sentence adds value without redundancy, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (so return values need not be detailed), the description covers purpose, usage guidance, behavioral traits, and OAuth scope. For a metadata inspection tool, this is fully complete and leaves no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so baseline is 3. The description adds minimal extra meaning for the parameters themselves, but does provide context that the output is metadata (title, locale, tabs, sizes). This is adequate but does not exceed expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it inspects spreadsheet metadata (title, locale, tabs, sizes) and distinguishes itself from siblings like read_sheet_values by noting it does not read cell values. It also lists specific sibling tools it supports (read_sheet_values, manage_sheet_tabs, protect_sheet_range), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: to discover sheet names and sheetIds before calling certain sibling tools. It also clarifies what the tool does NOT do (read cell values), directing users to read_sheet_values for that. This provides clear guidance on appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses read-only nature (via 'Fetch' and 'tasks.readonly' scope) and lists returned fields. Lacks mention of error cases, but sufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and uses 5 sentences without redundancy. Each sentence adds value, including return details, sibling guidance, and OAuth requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description covers return fields, OAuth scope, and alternative tools. It is fully adequate for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds meaningful context by specifying that IDs come from other tools (list_task_lists and list_tasks), which aids correct parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a single Google Tasks task by ID' and lists the returned fields. It explicitly distinguishes from siblings: 'For the full list of tasks in a list use list_tasks. For mutations use manage_task.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use this tool vs alternatives (list_tasks for list, manage_task for mutations) and specifies the required OAuth scope, providing clear context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description notes immutability (cannot be edited), error on non-existent version (404), and required OAuth scope. Could mention that it only returns metadata, not code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Few sentences, well-structured with bullet points for alternatives. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values not needed. Description covers purpose, usage, prerequisites, alternatives, and error behavior—complete for a metadata retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter descriptions. Description adds value by explaining version concept, 1-indexing of version_number, and error handling, going beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fetch metadata for a specific immutable version', with verb and resource. It differentiates from siblings like list_versions, create_version, and list_deployments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool ('inspect the description/create-time of one known version') and when to use alternatives (list_versions, create_version, list_deployments).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses a key side effect: chip rendering happens client-side and the API only stores a linked URL. It also calls out the OAuth scope requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, tightly packed with actionable information: purpose, side effect, alternatives, and auth. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters (3 required) and an output schema present, the description covers purpose, side effects, usage context, and auth. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add parameter details. Baseline 3 applies; the description adds no extra parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Insert a Drive-file smart chip at an index in a Google Doc,' providing a specific verb and resource. It distinguishes from siblings like insert_doc_person_chip and insert_doc_link by explicitly naming alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use this tool versus alternatives ('For a person @mention use insert_doc_person_chip; for a plain hyperlink use insert_doc_link') and mentions the required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses auto-conversion of Drive IDs, index 0 bump to 1, and OAuth scope requirements. Lacks error handling details but is otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and front-loaded with main action. Each sentence adds value without redundancy. No fluff or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, return values need not be explained. All 6 parameters covered, behavior well-described, prerequisites and scope noted. Complete for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by explaining image_source types and auto-conversion, index bump, and width/height default meaning (0=auto-size). Enhances schema understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Insert an image into a Google Doc from Drive or an HTTPS URL,' specifying the verb, resource, and data sources. It distinguishes itself from sibling tools like insert_slides_image (for Slides) and insert_doc_elements (more general).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use and prerequisites: Drive files must allow 'Anyone with the link' and suggest checking with check_drive_file_public_access; HTTPS URLs must be direct image bytes. Also mentions supported formats and index behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 key behaviors: conversion to Docs API batch requests, rendering with real Docs styles (not raw markdown), and supported markdown elements. However, it does not mention error handling for invalid markdown or potential size limits, which would make it fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) and front-loaded with the core purpose. It efficiently compares to siblings, lists supported features, and mentions scope, with no redundant or trivial information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (return values not needed) and schema coverage is 100%, the description covers all key aspects: purpose, alternatives, supported syntax, scope, and parameter semantics for the main parameter. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by detailing supported markdown syntax for the 'markdown' parameter, going beyond the schema's 'Markdown source to insert.' Other parameters are not enriched beyond schema, but the addition to the most critical parameter justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it inserts markdown with native styling into a Google Doc. It specifies the verb-resource pair ('Insert markdown-formatted content into a Google Doc') and explicitly distinguishes from siblings modify_doc_text (plain text) and find_and_replace_doc (find-replace).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance (for markdown insertion with native styling) and when-not-to (use modify_doc_text for plain text, find_and_replace_doc for patterns). It also lists supported markdown syntax and notes the required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Though no annotations exist, the description clarifies the data source (people/me) and OAuth scope. Implied read-only operation, but does not explicitly mention pagination behavior or other nuances. Absence of annotations makes description carry full burden; it adequately covers key behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, alternative tools, and scope requirement. No extraneous information, well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, with an output schema and fully described parameters, the description provides all essential context: purpose, usage guidance, and authentication requirements. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds context that contacts are personal and from the authenticated user, which supplements the parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists the authenticated user's personal Google contacts from 'people/me', distinguishing it from sibling tools like list_contact_groups (groups), search_contacts (fuzzy search), and manage_contacts_batch (batch mutations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use this tool vs alternatives, referencing sibling tools by name. Also specifies the required OAuth scope, setting clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes non-obvious behaviors: only direct children returned, trashed excluded, shared drive flags needed, and error handling for invalid folders. No annotations were provided, so description carries full burden and meets it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with purpose, then usage, behavior, auth. Every sentence adds value without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers scope, alternatives, recursion, shared drives, trashed items, auth scope, and error behavior. Output schema exists so return details not needed. Complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and schema already has detailed descriptions for each parameter (e.g., folder_id explains default, shared drives, error). Description does not add further parameter details, but baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'list all Google Docs directly inside a given Drive folder', specifying verb, resource type, and scope. Distinguishes from siblings like search_docs and list_drive_items by stating when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (enumerate Docs in known folder) and when not to, naming alternatives (search_docs for name search, list_drive_items for non-Docs). Also explains no recursion and shared drive support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It correctly identifies as a read operation (OAuth read scope). Mentions pagination and basic metadata. Could be improved by noting it only returns submitted responses and any rate limits, but still good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with main purpose, then usage flow, then auth. Every sentence adds value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, output schema present, the description covers purpose, usage guidance, pagination, auth, and integration with siblings. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by explaining page_size caps and default, page_token one-shot nature, and required OAuth scope, going beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists form responses with basic metadata (response IDs, timestamps, answer counts) and is paginated. Distinguished from sibling tools like get_form_response (full payload) and get_form (structure).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly guides to use this for discovery of response IDs and timestamps, then use get_form_response for full details, and get_form for form structure. Provides clear when-to-use and when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: side effects of create (two API calls atomically) and destructiveness of delete. It also discloses the OAuth scope requirement, going beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loaded: first sentence states purpose, second covers side effects, third gives alternatives, fourth notes OAuth. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (CRUD with side effects and OAuth), the description covers purpose, side effects, alternatives, and authorization. Input schema handles parameters, and an output schema exists (per context), so return values are covered. The description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter. The tool description adds no additional parameter-level meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create, update, or delete an Apps Script deployment', providing a specific verb and resource. It distinguishes itself from siblings by explicitly naming list_deployments for listing and run_script_function for execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use this tool (for CRUD operations on deployments) and when not to (listing via list_deployments, code execution via run_script_function). It also mentions the required OAuth scope, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden, disclosing side effects ('mutates calendar state', 'Delete is destructive'), attendee notifications, and required scope. This is comprehensive for safe agent usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with core purpose, followed by side effects and alternatives. Every sentence earns its place with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 25 parameters, an output schema, and no annotations, the description provides essential context: purpose, side effects, alternatives, and required scope. It is complete for safe and effective usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds no additional parameter-specific semantics beyond the action types. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create, update, delete, or RSVP to a calendar event.' It uses a specific verb and resource, and distinguishes itself from siblings like get_events and manage_focus_time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when to use this tool vs alternatives: 'For read-only fetches use get_events; for focus-time blocks use manage_focus_time.' It also mentions side effects and required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses side effects (persistent auto-action rule creation or permanent deletion) and the required OAuth scope. It also notes the lack of update support, which is critical behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that cover purpose, side effects, workaround, prerequisite, and auth requirement. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, create/delete) and the presence of an output schema, the description covers all essential behavioral context, including side effects, unsupported operations, recommended usage, and auth scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and parameter descriptions in the schema are thorough. The tool description does not add new meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or deletes a server-side Gmail filter, using specific verbs and resource. It distinguishes from sibling tools like 'manage_gmail_label' or 'list_gmail_filters' by focusing on filter management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions that filter updates are not supported and advises to delete and recreate instead. Also recommends using 'list_gmail_filters' first to inspect existing filters, providing clear 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses side effects: 'delete is destructive — removes the list AND all its tasks' and 'clear_completed hides completed tasks from default views (they remain retrievable via list_tasks with show_hidden=True).' Also specifies auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then side effects, then alternative tool and auth. Every sentence adds value. Highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple actions, destructive behavior, auth), the description covers all essential aspects. An output schema exists, so return values need not be described. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 4 parameters with 100% coverage. The description adds context on action behaviors but doesn't significantly enhance parameter-level meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create, rename, delete a task list, or clear its completed tasks.' It identifies the resource (task list) and the specific actions, and distinguishes from the sibling tool 'manage_task' which handles tasks inside a list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides guidance: 'For tasks inside a list use manage_task.' Also mentions the required OAuth scope, giving clear context on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses it returns only busy periods (not details), requires calendar.readonly OAuth scope, and is efficient for availability comparison. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences: purpose, usage with alternative, efficiency note, and auth requirement. No fluff, well front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (3 required) and existence of output schema, the description adequately covers purpose, usage context, behavior, and auth. It is complete for an agent to decide when and how to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add significant meaning beyond what the schema already provides for parameters like time_min, time_max, calendar_ids. It only mentions 'across one or more calendars' which is implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries busy-time windows across calendars, distinguishing from get_events for event details. It uses a specific verb-resource combination and explicitly names the sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (before creating an event to find conflicts/slots) and when not ('For event details use get_events'). Also notes it's efficient for multiple people/rooms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses output cap (50 rows) and OAuth scope requirement. No annotations provided, so description carries full burden. Cost info for hyperlinks/notes is in parameter descriptions but not main body.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with core purpose, each sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, limitations, alternatives, and authorization fully. Output schema handles return format, so description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds practical guidance on range parameter use due to output cap, providing semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Read cell values from an A1 range' with optional formulas/notes. Distinguishes from sibling tools modify_sheet_values and append_table_rows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool vs write/modify alternatives, and mentions output cap behavior and required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It explains scanning all text elements, batch operation, substring matching, idempotency (re-run no-op), and OAuth scope requirement. It lacks mention of whether it modifies the presentation in-place or potential rate limits, but covers most key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with five sentences that front-load the main purpose. Every sentence adds value: scope, batch nature, matching mode, alternatives, OAuth, and idempotency. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, output schema exists), the description covers all necessary aspects: scanning scope, matching mode, behavioral traits (idempotency, OAuth), and alternatives for scoped replacement. The existence of an output schema reduces the need to explain return values, but the description still hints at the return (0 occurrences). This is complete for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so baseline is 3. The description adds meaning beyond the schema: it clarifies that find_text is an exact substring match with literal newline interpretation, and explains match_case behavior (case-sensitive default, case-insensitive doesn't preserve original casing). This adds value for two parameters, lifting the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a find-and-replace of a literal string across all text elements in a Google Slides presentation. It specifies the resource (slides text) and scope (all slides, text boxes, shapes, table cells, speaker notes), distinguishing it from sibling tools like format_slides_text (scoped) and modify_doc_text (for Docs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides guidance on when to use this tool vs. alternatives: for global replacement, while for scoped replacement within a single element, it directs to format_slides_text or modify_doc_text. It also clarifies it's a batch operation with plain substring matching, no regex or wildcards, helping the agent decide appropriateness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool only changes the display title and does not move or delete content, and mentions required OAuth scope. This is transparent and aligns with expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (rename only) and the presence of an output schema, the description covers purpose, behavior, limitations, OAuth scope, and differentiation adequately. No missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so baseline is 3. The description adds no further meaning beyond the schema's parameter descriptions, which are already clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Rename an existing tab' and specifies the action is limited to changing the display title. It distinguishes from sibling tools insert_doc_tab and delete_doc_tab by explicitly naming them for creation and deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides guidance on when to use this tool (rename) and when not to, referring to insert_doc_tab for creation and delete_doc_tab for deletion, offering clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains behavior: it deletes existing notes and inserts new ones, and mentions that an empty string clears notes. It discloses a failure mode (slide without notes shape returns an error string), providing full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and every sentence adds value without redundancy. It is highly concise yet complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's straightforward nature, an existing output schema, and no annotations, the description covers purpose, behavior, failure modes, and alternatives. It provides all necessary context for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 75% coverage with descriptions for three of four parameters. The description does not add extra parameter-level details beyond the overall behavior, so it meets but does not exceed the baseline for the given coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Replace the speaker notes on a slide' with a specific verb and resource. It distinguishes from appending by saying 'NOT an append' and references a sibling tool for reading, providing clear purpose differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use (to replace notes) and when not (if you need to read first, use get_slides_speaker_notes). It also states the OAuth scope required, giving complete usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Details OAuth scope, creates exactly one shape per call, returns object ID, and explains transparent fill behavior. Could add more about error cases but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured, front-loaded with purpose, bullet points for alternatives, and clear notes. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (9 params, 4 required) and presence of output schema, description covers behavior, usage, parameters, and return value. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 89% (baseline 3). Description adds significant value: explains shape_type with common values and link, EMU units for position/size, and fill_color optionality. Exceeds baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates a shape element (rectangle, ellipse, etc.) on a Google Slide. Distinguishes from sibling tools like create_slides_text_box and style_slides_shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (build layouts programmatically) and when not (use create_slides_text_box for text, style_slides_shape for styling). Also mentions follow-up actions like adding text via batch_update_presentation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes internal behavior: uses Docs API for native docs and walks tabs; falls back to Drive download for .docx. Required scopes are listed. No annotations provided, so description carries full burden and does so well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose, then behavior and alternatives, then scopes. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, behavior, alternatives, and scopes adequately for a content retrieval tool. With output schema present, no need to describe return values. Minor omission: no mention of error handling for missing documents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions; description adds value by noting that document_id accepts full URLs, going beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Doc body text for both native Google Docs and .docx files, and distinguishes from siblings like get_doc_as_markdown and inspect_doc_structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides alternatives: 'For markdown output use get_doc_as_markdown; for structural inspection use inspect_doc_structure.' Also mentions required OAuth scopes, guiding appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the tool's read-only nature and details of its output fields (e.g., total_length, tables, headers). It also warns against inventing segment IDs, adding important behavioral context beyond what annotations would cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, bullet points, and a workflow format, making it easy to scan. However, it is somewhat verbose and could be trimmed (e.g., repeated emphasis on calling before table creation).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description thoroughly covers all aspects: purpose, usage, output fields, and workflows. It leaves no obvious gaps for an agent to understand how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema coverage is 100% and parameters are described clearly, the description adds value by explaining when to use the `detailed` parameter (e.g., in formatting workflow) and how `tab_id` affects output. This goes beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for 'finding safe insertion points and understanding document structure' and lists specific use cases like finding table insertion indices and locating existing tables. It distinguishes itself from siblings by focusing on structure inspection for table operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: before table creation, during formatting workflows, and for header/footer editing. It contrasts with `update_doc_headers_footers` for normal header/footer usage and includes step-by-step workflows for table insertion and formatting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains auto-pagination behavior, the hidden completed tasks nuance requiring both show_completed and show_hidden, and the required OAuth scope. This goes beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with two short paragraphs front-loading the purpose. Every sentence provides essential information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, filters, pagination), the description covers key behavioral aspects: auto-pagination, hidden tasks quirk, OAuth scope, and sibling differentiation. It doesn't detail date filters, but schema descriptions cover them, and output schema exists for return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds crucial context beyond schema, particularly the show_completed/show_hidden interaction and auto-pagination. This elevates the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists tasks in one task list with rich filters and auto-pagination. It distinguishes from sibling tools get_task and manage_task, and specifies the required OAuth scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly guides when to use this tool vs alternatives: 'For one specific task use get_task. For write operations use manage_task.' Also provides a specific caveat about hidden completed tasks and scope requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains behavioral traits like markdown's interaction with explicit formatting, the end_of_segment shortcut, and the safe use of segment_id. However, it lacks details on error cases or what happens when indices are out of bounds.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured: first sentence summarizes purpose, then tips, markdown mode, and warnings. Every sentence adds unique value; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 22 parameters, high schema coverage, and an output schema, the description covers key behavioral points: markdown mode constraints, index calculation tip, sibling differentiation, and segment ID guidance. It addresses the most common use cases and pitfalls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 95%, so baseline is 3. The description adds significant value by explaining end_of_segment, format_as_markdown limitations, segment_id origin requirements, and start_index alias (0 accepted). These go well beyond the schema's brief descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool modifies text in a Google Doc, supporting insert/replace and/or formatting in one operation. It distinguishes from siblings by explicitly recommending update_doc_headers_footers for header/footer text and warning against guessing segment IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: preferring update_doc_headers_footers for header/footer text, setting end_of_segment=true for simple appends, and using markdown mode for formatted text. Also warns not to guess segment IDs, covering both when to use and when to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses side effects (mutates label set) and required OAuth scope (gmail.modify). Could add more on error handling or idempotency, but covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, front-loaded purpose, then side effects, recipes, alternatives, and scope. Every sentence adds value; no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary context: usage boundaries, parameter specifics, side effects, permissions, and relationships to siblings. Output schema exists, so return values are handled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond schema: explains that label IDs must be system IDs or user label IDs (names do not work), and that message_id comes from search_gmail_messages. This prevents common mistakes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add or remove labels on one Gmail message', specifying verb and resource. It distinguishes from sibling tools like batch_modify_gmail_message_labels and manage_gmail_label, ensuring no confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use batch_modify_gmail_message_labels for bulk operations, use manage_gmail_label for creating/deleting labels. Also includes common recipes (archive, delete, star) and required OAuth scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully carries the burden. It discloses the query method (Drive files.list with name contains), mimeType filter, exclusion of trashed docs, OAuth scope requirement, auto-escaping of single quotes, and the absence of pagination token. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but well-structured with clear sections. Each sentence adds informational value, and it avoids unnecessary fluff. It could be more concise, but it is far from wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (3 params, full schema coverage, output schema exists), the description is very complete. It explains the underlying API, scope, limitations, and provides alternatives, leaving no critical gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters (100% coverage). The description adds value by explaining case-insensitivity, auto-escaping, empty string behavior, and page_size cap, which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: searching Google Docs by filename substring across the user's entire Drive. It specifies the action, resource, and scope, and distinguishes from sibling tools like search_drive_files and list_docs_in_folder by explaining the underlying query method and limitations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool ('name-only lookups') and when not to use it ('does NOT search document content; for full-text search use search_drive_files'). It also provides alternatives for listing docs in a folder, giving clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, description fully carries burden: discloses OAuth write scope, idempotent behavior, safe re-execution, rate limit context, and a specific error case (image element returns no-op). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three-sentence structure: purpose, guidelines, behavioral notes. No fluff, front-loaded with key info. Every sentence adds distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, return values not needed. Description covers how to obtain page_element_id, scope requirements, error behavior, and parameter application scope (all paragraphs vs. range). Complete for a 10-param formatting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (90%), but the description adds value by summarizing parameter groups (alignment, spacing, bullets) and clarifying 'Omit to leave unchanged' for each. Bullet preset examples add meaning beyond enum-less schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb+resource: 'Apply paragraph-level formatting (alignment, spacing, bullets) to text inside a shape, text box, or table cell on a Google Slide.' Explicitly distinguishes from siblings format_slides_text and style_slides_shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (paragraph concerns) and when-not-to (character-level, shape styling) with specific alternative tool names. Also mentions idempotence and rate limits for safe usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It details the insertion behavior (preserving order, index computation after removal, clamping out-of-range values) and side effects (requires write scope, mixing IDs is an error). This fully discloses the tool's behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear lead sentence, followed by organized paragraphs. Each sentence adds value (e.g., index calculation, alternatives, errors). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (reordering with multiple slide IDs, index logic) and the presence of an output schema (indicated by context), the description is complete. It covers the core behavior, index details, error conditions, and permissions. The output schema (not shown) likely explains return values, so no further description needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (3 of 4 parameters have descriptions). The description adds significant meaning beyond the schema: explains slide_object_ids order preservation with example, and insertion_index computation after removal with clamping behavior. The user_google_email parameter lacks description but is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move one or more slides to a new position') and the resource ('the deck'). It distinguishes itself from sibling tools like duplicate_slide and format_slides_* by explicitly stating what it does and does not do (e.g., not reordering page elements).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance ('Reorders slides...') and when-not-to-use ('does not reorder page elements...'). It directly points to an alternative tool (batch_update_presentation with updatePageElementZOrder) for different needs. Also includes required OAuth scope and error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: the operation creates a new revision, preserves file metadata, requires write scope, may be slow for large files, and fails with an explanatory error for Google-native files. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet thorough, with clear sections and bullet points. It front-loads the main action and efficiently conveys limitations and alternatives without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the operation and the presence of an output schema, the description covers all necessary context: behavior, prerequisites, limitations, and error cases. It is 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, and the description adds valuable context for file_id and revision_id (how to obtain them, constraints). The user_google_email parameter lacks description in both schema and description, but the overall guidance for two key parameters is strong.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Restore a Drive file's content to a previous revision.' It distinguishes this tool from siblings like 'get_drive_revisions' or 'update_drive_file' by explaining the unique mechanism (download+upload) and that it creates a new revision rather than rewinding history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly covers when to use (non-Google-native files) and when not (Google-native files), provides an alternative (use Google Docs UI), and lists prerequisites (OAuth scope, file and revision IDs). This guides the agent effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: fetches image at insert time, embeds reference, requires public URL, formats, OAuth scope, return value, size limits, and EMU defaults. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise paragraph with clear first sentence and structured details. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, and an output schema (implied), the description covers behavior, constraints, return value, sizing, and defaults comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond the schema: explains EMU conversions, default positioning, aspect ratio warning, and image size limits. Schema coverage is 88%, but description compensates for missing user_google_email description with other rich details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inserts an image onto a slide from a URL, with specific verb and resource. It distinguishes from siblings like insert_doc_image (for Docs) and create_slides_shape (for shapes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instructions: URL must be publicly accessible, supported formats, OAuth scope required, returns object ID, and size limits. Tells when to use and when not (e.g., private URLs, SVG).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature via OAuth scope, notes no pagination token is exposed, and explains scope of results (only joined spaces). No annotations exist, so description carries full burden and meets it well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, each adding unique value. Front-loaded with purpose. No redundancy or unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, limitations, auth, and parameter details. Given the presence of an output schema (context signal), describing return values is unnecessary. Complete for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaningful context beyond the schema: explains page_size default and Google hard cap, details space_type filter options, and notes pagination limitation. Schema coverage is 100% but description enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List Google Chat spaces' with specific verb and resource. Distinguishes from sibling tools by explaining its role in discovering space_id for get_messages, send_message, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use ('discover the space_id needed for get_messages, send_message') and what it cannot do ('will not surface public spaces the user hasn't joined').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ve-gws MCP server](https://glama.ai/mcp/servers/HuntsDesk/ve-gws/badges/card.svg)](https://glama.ai/mcp/servers/HuntsDesk/ve-gws)

Score Badge

Copy to your README.md:

[![ve-gws MCP server](https://glama.ai/mcp/servers/HuntsDesk/ve-gws/badges/score.svg)](https://glama.ai/mcp/servers/HuntsDesk/ve-gws)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/HuntsDesk/ve-gws'

If you have feedback or need assistance with the MCP directory API, please join our Discord server