Google Workspace MCP Server

Server Quality Checklist

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

Latest release: v1.24.1
Disambiguation3/5
Most tools are cleanly separated by Google service and resource, but there are several confusable pairs: get_drive_file_content and get_doc_content both fetch file content by ID, search_drive_files and search_docs overlap, and set_drive_file_permissions vs. manage_drive_access blur the permission-management boundary. The long, detailed descriptions help agents choose correctly, so the overlap is manageable rather than severe.
Naming Consistency4/5
The set overwhelmingly follows a lowercase snake_case verb_noun pattern with useful service prefixes such as gmail_, drive_, doc_, and script_. Minor deviations like search_custom, set_publish_settings, get_messages, and debug_docs_runtime_info break the otherwise predictable convention, but the overall pattern is still clear.
Tool Count1/5
With 124 tools, this server is far beyond the 50+ extreme threshold and would overwhelm an agent's tool-selection space. The breadth reflects the many Google Workspace services, but as a single coherent MCP tool set it is drastically over-scoped.
Completeness3/5
Coverage is impressively broad across Gmail, Drive, Calendar, Docs, Sheets, Chat, Forms, Slides, Tasks, Contacts, Search, and Apps Script. However, there are notable gaps: no Drive delete/trash operation exists, which also prevents agents from deleting Docs, Sheets, and Slides files, and calendar metadata management is essentially create-only.
Average 3.8/5 across 124 of 124 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 180 commits in the last 12 weeks
- No stable releases found
- 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.
Add related servers to improve discoverability.

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?
Annotations already disclose readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate safety. However, it also adds no behavioral context such as authentication requirements, scope of the returned form, or relationship to Google user email.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this reads as under-specification rather than effective conciseness. It contains only a restatement of the tool name and provides no useful elaboration.
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 schema covers parameters completely, annotations cover safety semantics, and an output schema exists, so the tool is minimally callable. Still, the description omits any context about the form object versus form responses, which limits completeness for an agent navigating many form-related siblings.
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 fully documents both required parameters (user_google_email and form_id) with clear descriptions, so the description does not need to compensate. It also adds no extra meaning 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 names a specific verb and resource: retrieve a form. It is clear about the core operation, but it does not differentiate from sibling tools like get_form_response or list_form_responses, which also involve forms.
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, when to prefer get_form_response, or what distinguishes retrieving a form definition from retrieving responses.
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 annotations already indicate a non-read-only, non-idempotent write operation, and the description adds no additional behavioral traits. It does not disclose authorization needs, side effects, or error behaviors beyond the basic fact that a message is sent.
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 with no filler or repetition. Every word contributes to identifying the core operation.
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 five parameters, optional threading, likely authentication needs, and the large sibling set, the description is under-specified. It lacks routing context, auth prereqs, and thread semantics, though an output schema exists to cover return values.
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 only 40%, and the description does not compensate for the undocumented required parameters (user_google_email, space_id, message_text). It implies message_text is the content and space_id is the destination, but it leaves user_google_email's role and the distinction between thread_key and thread_name unexplained.
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 names a concrete action ('sends') and a specific resource ('Google Chat space'), which distinguishes it from the Gmail-sending sibling. It does not explicitly differentiate among Chat siblings like get_messages or create_reaction, but the verb+resource is specific enough for basic selection.
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?
There is no guidance on when to use this tool versus alternatives such as send_gmail_message or Chat read tools. No preconditions, caveats, or selection criteria are mentioned, leaving the agent to infer usage from the tool name and context.
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 annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is known. However, the description adds no behavioral detail beyond that: it does not mention atomicity, partial failure, irreversible changes, or what kinds of modifications can be applied.
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 front-loaded sentence with no filler. It is efficient and clear, though slightly under-specified for the complexity of the operation.
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?
This is a destructive, open-ended batch operation with an unstructured requests array, but the description is only one generic sentence. It leaves out valid request categories, failure semantics, and usage context. The presence of an output schema covers return values, not operational guidance.
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 schema already provides 100% parameter coverage, so the bar for the description is lower. The description adds no parameter-level context beyond the schema, and the open-ended 'requests' array in particular would benefit from an example or explanation of the expected shape.
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 action ('apply batch updates') and the resource ('Google Slides presentation'), which is enough to differentiate it from read/create tools like get_presentation and create_presentation, and from the Docs/Forms batch update siblings by resource. It does not enumerate update types or scope, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as create_presentation, get_presentation, or batch_update_doc. An agent must infer from the name and sibling list that this is the choice for batch-mutating an existing Slides presentation.
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?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the description's 'inserts' adds little beyond confirming a write operation. It does not disclose behaviors like index validity constraints, whether insertion shifts existing content, or side effects of repeated calls at the same index — meaningful gaps for a mutation tool flagged openWorldHint=true.
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?
One front-loaded sentence with no filler; every word earns its place. It is slightly under-structured in that a brief clause pointing to an alternative sibling would have made it near-optimal, but as written it is efficient and scannable.
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 schema (100% coverage) and output schema carry parameter and return semantics, and annotations carry the safety profile, so the description is not obliged to repeat those. However, for an 8-parameter mutation tool with openWorldHint=true, the missing usage differentiation and insertion-behavior context leave noticeable gaps in what an agent needs 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?
Schema description coverage is 100%, so every parameter (element_type, index, rows, columns, list_type, text, etc.) is already documented in the schema. The description's mention of tables/lists/page breaks mirrors the element_type enum values and adds no new semantic meaning, warranting the baseline 3.
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 uses a specific verb ('Inserts') and names the resource (Google Doc) plus concrete element types (tables, lists, page breaks), which distinguishes it from obvious text/image siblings like modify_doc_text and insert_doc_image. It does not, however, differentiate from overlapping doc siblings such as create_table_with_data and batch_update_doc, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use/when-not-to-use guidance or alternatives are given. Given the dense sibling list with overlapping capabilities (create_table_with_data for tables, batch_update_doc for arbitrary doc updates), an agent gets no criteria for choosing this tool over those. Usage is only weakly implied by the description's purpose statement.
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?
Annotations already disclose the destructive, non-read-only, non-idempotent nature, and the description adds no behavioral context beyond the bare operations. Important caveats about update overwrite risk and field-specific behavior appear only in the schema, not in the description.
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?
Two concise sentences with no filler. It front-loads the core action and provides consolidation context, though it is slightly terse for a complex batch mutation tool.
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 schema and annotations carry most of the necessary context, including per-parameter semantics and destructive behavior. However, the description does not provide a high-level overview connecting actions to their required inputs (contacts vs updates vs contact_ids), which would help an agent plan a batch operation safely.
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 each parameter has detailed descriptions, including action enums, field constraints, and which parameter applies to which action. The description adds no parameter information, but none is needed given the thorough 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 states a specific verb ('Batch create, update, or delete contacts') and a resource, clearly indicating the tool's consolidated purpose. It distinguishes itself from the replaced batch_* tools, though it does not explicitly contrast with current siblings like 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 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 batch tool versus the singular manage_contact, nor which action requires which parameter set. The phrase 'Consolidated tool replacing...' references tools that are no longer in the sibling list, so it provides little actionable routing for an agent.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so safety is covered by structured metadata. The description adds no behavioral context beyond the API name, such as quota usage, authentication needs, or result variability. There is no contradiction with the annotations.
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 front-loaded sentence with no filler or repetition. It is concise, though slightly under-specified for a tool with 13 parameters and many sibling search tools.
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?
The output schema and annotations cover return values and safety traits, so those gaps are filled by structured data. However, the description does not clarify what kind of content search_custom searches, when to choose it over sibling search tools, or what domain-specific setup (e.g., a configured custom search engine) might be required. For a tool with 13 parameters and a large sibling set, this one-liner is not complete enough.
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 every parameter, default, and constraint is already documented in the input schema. The description contributes no additional parameter meaning, but the high schema coverage means the description does not need 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 states a clear action ('Performs a search') and identifies the specific API ('Google Custom Search JSON API'), which is distinct from sibling search tools for Gmail, Drive, Docs, and other services. It does not explicitly describe the search scope (web, sites, images), but the API name and parameter schema provide enough orientation.
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 gives no guidance on when to use this tool versus alternatives such as search_drive_files, search_gmail_messages, or search_docs. It also does not mention prerequisites, exclusions, or typical use cases. An agent must infer all usage context from the tool name and schema.
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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context about the mimeType filter and return format, but does not disclose pagination, query syntax, or any limitations. With annotations covering the safety profile, a 3 is appropriate.
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 short sentences with no filler. The core action and return type are front-loaded, and 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?
Even with output schema and annotations available, the description omits essential context such as how the query string should be formatted, the meaning of user_google_email, and the behavior of page_size. For a 3-parameter tool with zero schema descriptions, the definition is incomplete.
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 only clarifies that 'query' searches by name; it does not explain 'user_google_email' or 'page_size'. The description leaves most parameter semantics to inference.
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 uses a specific verb ('searches'), a specific resource ('Google Docs'), and explains the mechanism ('Drive API (mimeType filter)'). This clearly differentiates it from generic Drive file search, although it does not explicitly name a 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like search_drive_files or list_docs_in_folder. The description only states what the tool does, not when it should be preferred.
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?
The annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive). The description adds minimal behavioral context by stating it returns a formatted list, but it does not disclose recursion behavior, auth requirements, or pagination 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 brief and front-loaded with the core purpose. The Returns line is a slight redundancy given an output schema exists, but overall the description is appropriately sized and easy to scan.
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?
This is a low-complexity read-only tool with rich annotations and an output schema, so the missing return details are not critical. However, the complete absence of parameter explanation and any usage routing leaves the definition only minimally viable.
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%, so the description must compensate for parameter meaning. It does not explain user_google_email, folder_id, or page_size. Even the folder concept is only implied by the tool name and one phrase, not by any parameter-level documentation.
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 and resource: 'Lists Google Docs within a specific Drive folder.' This clearly distinguishes it from sibling tools like list_drive_items (all items) and search_drive_files (search across Drive).
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?
There is no guidance on when to use this tool versus alternatives such as list_drive_items or search_docs. The description states what it does but offers no context, prerequisites, or exclusions.
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?
Annotations already cover read-only, idempotent, open-world, and non-destructive behavior, so the description adds no new behavioral context. It does not mention pagination behavior, response ordering, or any other trait beyond what annotations and schema already provide.
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 one short, front-loaded sentence with no filler or unnecessary detail. It is concise, though it largely restates the title and provides no additional structural 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?
For a simple list operation with a full output schema, rich annotations, and complete parameter documentation, the description is sufficient to call the tool correctly. The main gap is usage guidance relative to sibling tools, which is already accounted for in that dimension.
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 four parameters are fully described in the input schema (100% coverage), so no compensation is needed from the description. The description itself adds no parameter-level meaning, which is acceptable given the complete 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 states a specific verb ('List') and resource ('a form's responses'), making the operation clear. It does not explicitly mention sibling tools like get_form_response, so the agent must infer the collection-versus-single distinction from the plural noun and tool name.
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 is a single clause with no guidance on when to use this tool versus alternatives such as get_form_response or get_form. There are no stated conditions, exclusions, or routing hints for the agent.
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?
Annotations already declare destructiveHint=true, readOnlyHint=false, so the safety profile is set. The description adds no behavioral context: it doesn't mention that 'delete' permanently removes events, that 'update' may edit shared calendars, that attendee emails get notified via send_updates, or that rsvp changes the calendar owner's response rather than the event itself. Given the destructive action and broad scopes, this is a significant gap.
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 main description is a single 11-word sentence that front-loads the resource and action set, then the action parameter enumerates the four verbs. It earns its place. The schema descriptions are verbose but structured; the only redundancy is the title 'Manage Event' nearly duplicating the function name 'manage_event'.
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 30 params and an output schema, the description never explains which action requires which parameters, what the MCP returns per action, how Google Meet/conference params interact, or the implied notifications on mutation. An agent must open the schema and infer the entire action-behavior contract. The high schema coverage helps parameter semantics but doesn't compensate for the missing action-specific behavioral guidance.
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 fully documents all 30 parameters with descriptions. The tool description itself repeats no parameters. The one gap is that the description doesn't synthesize per-action parameter requirements (e.g., create needs start_time/end_time/summary; delete needs event_id). Baseline 3 is right because the schema does the heavy lifting, but the cross-parameter action matrix is not explained anywhere.
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 identifies the resource (calendar events) and lists the four supported actions (create, update, delete, RSVP), with the action parameter enumerating them. The name 'manage_event' and title 'Manage Event' are generic, but the description adds concrete action detail.
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 gives no explicit guidance on when to use this tool versus alternatives like get_events or manage_focus_time, and it doesn't explain that CRUD for events belongs here while read operations live in get_events. The broad verb 'manages' implies the usage context but doesn't state exclusions or prerequisites such as requiring completed Google auth.
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?
Annotations already cover the safety profile (non-read-only, non-idempotent, non-destructive), so the bar is lower. The description adds useful context — the copy 'maintains all formatting and content from the original' and can be placed in a new location — but omits copy-specific behavioral caveats such as whether sharing settings or permissions are inherited by the copy, which agents often need for Drive operations. No contradiction with annotations.
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 compact sentences with the core purpose front-loaded in the first. The third sentence earns its place by adding the fidelity guarantee (formatting and content preserved), while the second is largely redundant with the first plus the schema — a minor flaw, not a structural problem.
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 output schema and 100% parameter coverage give the agent a complete input contract, and annotations cover mutability and safety, so return values need no explanation. What is missing are copy-specific caveats that matter for correct invocation: whether permissions are inherited by the copy, whether a copied native Google file stays in its original format, and the access required on the source file.
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 schema already documents file_id, new_name including the 'Copy of [original name]' default, parent_folder_id defaulting to root, and user_google_email. The description restates 'new location' and 'optional new name' at a high level but adds no meaning beyond what the schema's parameter descriptions already provide.
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 first sentence names a specific verb+resource: 'Creates a copy of an existing Google Drive file,' which clearly separates it from creation tools like create_drive_file. However, it never explicitly names a sibling it is NOT, and the second sentence's reference to 'the template document' slightly muddies whether this operates on one specific template or on any arbitrary 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No sentence tells an agent when to choose this tool versus alternatives such as create_drive_file (blank new file), import_to_google_doc (converting imports), update_drive_file (editing an existing file), or get_drive_file_content (reading). Among roughly 100 sibling tools, the only routing signal is the word 'copy' itself, which is definitional rather than actual usage 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?
Annotations already establish that this is a mutating, non-idempotent operation, so the bar is lower. The description adds a small behavioral detail about the title coming from 'the provided form message,' but it doesn't clarify side effects, authentication needs, or the created form's lifecycle.
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, front-loaded sentence with no filler. However, the phrasing 'using the title given in the provided form message in the request' is roundabout and slightly hurts clarity, preventing a top score.
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 creation tool, the full schema, annotations, and output schema carry much of the burden. The description is mostly sufficient, but it leaves a gap around when to use create_form versus form-update tools, and it never clarifies what 'provided form message' means.
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 input schema already fully documents the parameters. The description adds no meaningful parameter semantics beyond the schema, and the phrase 'title given in the provided form message' could even create confusion about the source of the title parameter.
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 states a specific action and resource ('Create a new form'), and the word 'new' distinguishes it from update/get form siblings. The tail clause about 'provided form message' is ambiguous, but the core purpose is still clear.
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 gives no guidance about when to use this tool versus alternatives like batch_update_form, get_form, or set_publish_settings. It also doesn't mention prerequisites such as completing authentication or requiring an authenticated Google account.
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?
Annotations already indicate this is a mutating, non-idempotent operation, so the safety profile is covered. The description adds that this creates a new project rather than modifying an existing one, which is useful but minimal. It does not disclose details such as whether the project is created in Drive, what happens if a project with the same title exists, or whether any additional resources are implicitly created. No contradiction with annotations exists.
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 with no wasted words, making it easy to parse and front-loaded with the key verb and noun. It is appropriately concise for a simple creation tool, though it could have used the brief format to add a bit more context without becoming verbose.
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 output schema and annotations, the description covers the basic action but lacks context about the project lifecycle, the role of parent_id, and the need for prior Google authentication. The sibling list hints at a script-project management workflow, but the description does not explicitly connect this tool to that workflow. It is minimally viable but leaves the agent to discover important surrounding context elsewhere.
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, including title, parent_id, and user_google_email. The description adds no additional meaning about these parameters or their relationships. This is the expected baseline case where the schema carries the parameter documentation burden.
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 uses a specific verb and resource: 'Creates a new Apps Script project.' It clearly distinguishes this from sibling tools like list_script_projects, get_script_project, update_script_content, and delete_script_project by focusing on creation. It does not state the broader context of what an Apps Script project is, but the core purpose is unambiguous.
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?
There is no guidance about when to use this tool versus alternatives, such as when to use create_script_project instead of create_drive_file or update_script_content. The description does not mention prerequisites like prior authentication or the relationship to other script-management tools. Agents are left to infer usage from the tool name and sibling list.
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 annotations already declare this as read-only, idempotent, non-destructive, and open-world, so the safety profile is covered. However, the description itself adds no behavioral context beyond 'get details,' such as scope limitations, authentication requirements, or response characteristics. It neither contradicts the annotations nor contributes meaningful behavioral disclosure beyond them.
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, efficient sentence that immediately states the action and object. There is no filler, repetition, or unnecessary elaboration.
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?
For a simple read operation with two fully documented required parameters, an output schema, and strong annotations, the description is largely complete. It lacks a brief pointer to list_task_lists for ID discovery, but the core invocation needs are satisfied by the schema and annotations.
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%, with both parameters clearly documented in the input schema. The description does not add further semantic detail about the parameters, but the schema already carries the burden, so the baseline 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 uses a specific verb and resource: 'Get details of a specific task list.' It clearly identifies the operation as retrieving one list by ID, and the required task_list_id parameter reinforces this. It does not explicitly contrast with sibling tools like list_task_lists or get_task, but the resource and scope are unambiguous enough.
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 when-to-use guidance is provided. The description does not mention that list_task_lists should be used first to discover task_list_id, nor does it explain when get_task_list is preferred over list_task_lists or how it differs from get_task. The agent must infer usage from the name and parameters.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds only the vague qualifier 'recent' and does not clarify what timeframe that implies, whether processes include running vs. completed ones, or how pagination behaves. There is no contradiction with the annotations.
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 definition is a single, front-loaded sentence with no filler. It efficiently communicates the action and resource, though its brevity contributes to the lack of usage and behavioral context. Strong on conciseness, slightly weak on completeness.
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 list operation with full schema coverage, safety annotations, and an output schema, the description is nearly enough. However, it does not define what qualifies as a 'process', what 'recent' means, or how this relates to get_script_metrics. These gaps keep it from being fully self-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 description coverage is 100%, so all three parameters are already documented with meaningful descriptions. The tool description's phrase 'user's scripts' loosely reflects user_google_email but adds no new semantic detail beyond the schema. The baseline of 3 applies.
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 states a specific action ('Lists') and a specific resource ('recent execution processes for user's scripts'). It is clearly distinguishable from obvious siblings like list_script_projects and run_script_function, though it does not explicitly separate itself from get_script_metrics, which could also relate to executions. Overall the core purpose is clear.
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 get_script_metrics or list_script_projects. There are no stated prerequisites, conditions, or exclusions. An agent is left to infer the correct context from the name and schema alone.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds that the result is a formatted string of spaces accessible to the user, but does not disclose pagination, ordering, or space-type filtering behavior beyond the schema's default. There is no contradiction with annotations.
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 short and front-loaded with the action in the first sentence. The second 'Returns' line is somewhat redundant but concisely specifies the return format. No rambling or unnecessary detail.
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?
For a simple list tool with strong annotations, the description is still incomplete because it omits any explanation of required parameter semantics and does not offer usage context such as discovering spaces before sending messages. With 0% schema coverage and no output schema details visible beyond 'str', the agent lacks enough guidance to filter spaces or understand the required email. The annotations cover safety, but not invocation semantics.
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 description provides no information about the three parameters. With schema description coverage at 0%, it does not compensate by explaining why 'user_google_email' is required or what 'space_type' and 'page_size' mean. The agent must rely solely on parameter names, which is insufficient for correctly invoking the tool.
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 a specific action ('Lists Google Chat spaces') and clarifies scope ('rooms and direct messages') and access ('accessible to the user'). It is clearly distinct from sibling tools like get_messages or search_messages, which handle message content rather than spaces.
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 use when needing to enumerate the user's spaces but gives no explicit when-to-use or alternative guidance. It does not mention that list_spaces is a prerequisite for messaging tools or contrast it with search_messages. Sibling differentiation is left mostly to the tool name.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'for the user' scoping, which is useful context. It does not disclose whether shared/delegated lists are included or how the 1000-item cap affects results, but with rich annotations the bar is lower and there is no contradiction.
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?
A single 8-word sentence with zero filler, and the key scope ('all', 'for the user') is front-loaded. It is efficient, though it borders on under-specification since it carries no usage or differentiation context.
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 read-only list tool, the schema covers parameters, annotations cover safety, and an output schema exists. The clear gap is routing: nothing tells the agent to prefer this over get_task_list or list_tasks, nor clarifies whether the result includes only the user's own lists. Adequate but not 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%, with all three parameters (page_token, max_results, user_google_email) already documented including defaults and the 1000 maximum. The description adds no parameter-level meaning, so the baseline 3 applies.
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 states a specific verb (List), resource (task lists), and scope (all, for the user), so it is not a tautology. However, it does not explicitly differentiate itself from the sibling get_task_list, leaving the agent to infer the single-vs-collection distinction.
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 close siblings such as get_task_list, manage_task_list, or list_tasks. No alternatives, exclusions, or selection conditions are mentioned, so the agent must infer usage context from the tool name alone.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description does not need to restate safety. The description adds the scoping to a single task list but does not mention filtering defaults, pagination, or that hidden/deleted tasks are excluded by default; saying 'all tasks' is slightly overstated relative to the default parameters.
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, direct, front-loaded sentence with no filler or redundant wording. It is appropriately concise for a read-only list operation, though it could have used an additional sentence to clarify filters or sibling relationships.
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 tool has 13 parameters, 2 required, and many task-related siblings, so a one-line generic description is thin. The output schema and rich parameter descriptions compensate partially, but the description still lacks guidance on when to choose this tool and what the default visibility/filter behavior is.
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 13 parameters, so the schema already carries the semantic burden. The description only adds the notion of 'specific task list', which maps to task_list_id, but it does not enhance understanding of filters, pagination, or default behaviors beyond what the schema provides.
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 uses a specific verb ('List') and resource ('tasks in a specific task list'), clearly identifying what the tool returns. It does not explicitly differentiate from sibling tools like list_task_lists or get_task, but the 'specific task list' phrasing helps disambiguate it from operations that manage task lists or individual tasks.
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 list_task_lists, get_task, or manage_task. The description only states what it does, with no mention of exclusions, prerequisites, or when a different task-related tool would be more appropriate.
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?
Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false, establishing a mutating, destructive profile. The description's action list is consistent with those annotations and adds the concrete 'clear completed tasks' behavior, but it doesn't disclose consequences such as whether delete or clear_completed are permanent or whether update merges or replaces list properties. It adds some value beyond annotations without contradicting them.
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?
A single 11-word sentence with zero filler; the action list is front-loaded immediately after naming the resource. The only minor redundancy is that 'Manage task lists' closely echoes the tool title, but the colon-structured format is efficient and scannable.
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 structured data carries most of the burden: a full output schema covers return values, per-parameter schema descriptions cover inputs, and annotations cover the safety profile. The main gap is that action-selection semantics—which task_list_id applies to which action and what clear_completed actually does—are only implied by the schema, not explained in the description. Adequate for a well-annotated tool, but not rich.
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 every parameter (title, action, task_list_id, user_google_email) already has a documented description, including which actions require which fields. The description only restates the action enum values already present in the schema, adding no new meaning. The baseline 3 applies since 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 names the resource (task lists) and enumerates four concrete actions (create, update, delete, clear completed), which makes the tool's scope specific. It is implicitly distinguished from siblings: manage_task operates on individual tasks, and list_task_lists/get_task_list are read-only counterparts. The generic opener 'Manage' is slightly weak, but the action enumeration compensates.
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. The description never mentions that list_task_lists/get_task_list are the read-only options for task lists, nor that manage_task handles individual tasks, and it doesn't explain when each action (create vs update vs delete vs clear_completed) is appropriate. With dozens of siblings, the agent must infer selection entirely from the schema.
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?
Annotations already signal a mutating operation (readOnlyHint=false) and non-destructive behavior (destructiveHint=false), so the description does not need to restate that. However, it adds no behavioral context beyond the single word 'Updates'—it does not explain immediate side effects, whether unpublishing affects existing responders, or what the output represents.
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 one short, front-loaded sentence with no filler or redundant content. It is concise without sacrificing clarity at the surface level.
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?
For a straightforward mutation tool with complete parameter schema coverage, annotations, and an output schema, the description is nearly sufficient. It lacks usage guidance and behavioral specifics, but those are partially offset by the rich structured metadata surrounding 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 100%, and each parameter already has a clear description and defaults. The tool description adds no additional parameter semantics, so the 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 uses a specific verb ('Updates') and resource ('publish settings of a form'), making the tool's core purpose immediately understandable. It is not a tautology, though it could more strongly differentiate itself from siblings like batch_update_form or create_form by naming the specific publish-related fields.
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 about when to use this tool versus alternatives such as batch_update_form or create_form. There are no prerequisites, exclusions, or conditions for choosing 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate that this is a mutating operation (readOnlyHint=false) and non-destructive (destructiveHint=false), and the description does not contradict them. The description adds the domain context that the created resource is a Google Spreadsheet, but it does not disclose side effects like Drive file creation, default sharing, or permission implications. This is acceptable given the annotations but lacks deeper behavioral detail.
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 one short, direct sentence that front-loads the core action and resource. Every word earns its place, and there is no redundant or filler content. For a simple creation tool, this is appropriately 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?
The input schema and output schema cover the technical details, so the description does not need to explain return values or parameter formats. However, given the large sibling toolset, the description lacks enough context to help an agent decide between 'create_spreadsheet' and related tools like 'create_sheet' or 'import_to_google_sheets'. It is minimally viable but incomplete for tool selection.
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 parameters 'title', 'sheet_names', and 'user_google_email' are already well documented in the schema. The description adds no additional parameter-level meaning, which is acceptable because the schema carries the full burden. This aligns with the baseline 3 for fully documented schemas.
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 action ('Creates') and the resource ('a new Google Spreadsheet'), so an agent can understand the core purpose. However, it does not differentiate from the sibling tool 'create_sheet', which could be confused as creating a spreadsheet rather than a worksheet within one. A more explicit distinction would earn a 5.
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?
There is no guidance about when to use this tool versus alternatives such as 'create_sheet', 'create_drive_file', or 'import_to_google_sheets'. The description gives no context about prerequisites, ownership implications, or which sibling tools are more appropriate in specific scenarios.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's minimal 'Get one response' is consistent. However, it adds no behavioral context beyond the annotations—such as account-scoping requirements or the need for prior listing—but there is also no contradiction.
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 compact sentence with no redundant words. It front-loads the essential action and object, making it easy to process quickly.
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 simple tool with a fully described schema, clear annotations, and an output schema, the description is mostly adequate. However, it misses the practical context of how response_id is obtained and how this tool relates to list_form_responses, leaving a minor but notable gap for an agent deciding how to retrieve a response.
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%, with all three parameters (form_id, response_id, user_google_email) individually described. The tool description adds no extra meaning to the parameters, so a baseline score of 3 is appropriate given the schema already documents them fully.
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 states a clear verb ('Get'), a specific resource ('one response'), and scope ('from the form'). It distinguishes itself from the sibling list_form_responses through the word 'one', but does not explicitly name the alternative or clarify that a specific response ID is required.
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 list_form_responses, nor does it mention that response_id must be obtained beforehand (e.g., via listing responses). An agent is left to infer usage entirely from the parameter schema.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read. The description adds little beyond the annotations; it says 'retrieves messages' but doesn't describe pagination behavior, default ordering, or that it may return only messages not yet deleted. No contradiction found.
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—one short sentence—and the parameter filter examples are helpful and well-structured. It is front-loaded with the core purpose. It could be slightly more informative, but it earns its place 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?
Given the presence of an output schema and rich annotations, the description doesn't need to explain return values. However, it lacks explicit guidance on how the message_filter syntax interacts with other parameters, pagination behavior, and required parameter semantics. It is minimally viable but not fully complete for an agent to call it with confidence in edge cases.
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 only 20%, so the description carries some burden, and it lists the main filter field and its supported syntax in detail (createTime and thread.name examples). However, it does not explain required parameters like user_google_email or space_id beyond their names, nor the order_by and page_size defaults. The filter details add real value over the schema, but gaps remain.
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 'Retrieves messages from a Google Chat space' uses a specific verb + resource and communicates the primary scope. It distinguishes itself from Gmail siblings by explicitly naming Google Chat, but does not differentiate from sibling tools like send_message, search_messages, or list_spaces, though the list verb is clear.
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_messages or get_gmail_messages_content. It doesn't state exclusions, prerequisites, or conditions. The only context is that it is Chat-specific, which is implied but not explicitly routed.
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?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that the tool returns metadata rather than content, which is mildly informative, but it does not discuss auth needs, rate limits, or which specific search engine is being referenced.
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 redundant wording, filler, or repeated annotation content. It is front-loaded with the action verb and direct object.
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?
This is a simple one-parameter read-only tool with an output schema and strong annotations, so the description only needs to be minimally complete. However, it leaves ambiguity about how the email parameter identifies the search engine and does not mention auth context, which slightly weakens 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?
The input schema fully describes user_google_email as the user's Google email address and marks it required, so schema coverage is 100%. The description adds no additional meaning about how this email maps to a specific Programmable Search Engine, so the baseline of 3 applies.
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 states a clear action ('Retrieves metadata') on a specific resource ('a Programmable Search Engine'), making the tool's basic function obvious. It is not a tautology and does not appear to overlap with content-returning siblings, but it does not explicitly differentiate itself from related tools like search_custom.
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 gives no guidance on when to use this tool versus alternatives, and it does not mention prerequisites such as completing Google authentication or whether this should be called before search_custom. Usage context is left entirely to the agent's inference.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the access-based scoping (spreadsheets the user can access, not merely owns), which is useful beyond the annotations. It does not mention pagination or ordering, but with annotation coverage the bar is met at a basic level.
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 12-word sentence that front-loads the verb and resource with zero filler. Every word earns its place and the core scope ('spreadsheets from Google Drive that the user has access to') is stated immediately.
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?
An output schema exists, so return values need no description; annotations cover the safety profile; and both parameters are fully documented. The real gap is tool-selection context: nothing distinguishes this from search_drive_files or list_drive_items, which matters in a sibling set this large. For a simple list operation, the definition is otherwise adequately 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%: both user_google_email and max_results are already fully described in the input schema, including the default of 25. The description adds no parameter-specific meaning, so the baseline of 3 applies.
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 uses a specific verb ('Lists') and a specific resource ('spreadsheets from Google Drive that the user has access to'), so an agent can tell this enumerates accessible spreadsheets. It implicitly distinguishes from siblings like list_drive_items (all files) and get_spreadsheet_info (single spreadsheet metadata), but it does not name any alternative sibling, so the differentiation is implicit rather than explicit.
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?
There is no when-to-use guidance, no exclusions, and no alternatives named. With roughly 90 siblings including search_drive_files, list_drive_items, and get_spreadsheet_info, the description gives the agent no textual basis for selecting this tool over those that could also surface spreadsheet data. The phrase 'that the user has access to' supplies minor scope context but no routing guidance.
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?
Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false. The description adds no context beyond those signals, such as whether deletion is irreversible, whether updates immediately change live deployments, or what authorization is needed. It is consistent with the annotations, so no contradiction, but it contributes no extra behavioral disclosure.
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 short sentences with no filler. The first sentence identifies the resource and the second enumerates actions; every sentence earns its place and the key scope is front-loaded.
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 definition is adequate because the rich input schema covers conditional requirements and the annotations cover the destructive profile, while an output schema exists. Still, a reminder that list_deployments should be used to find deployment IDs, or a note on consequences of deletion, would make the context more complete for a multi-action mutation 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%, with per-parameter explanations of action-specific requirements, such as deployment_id for update/delete, version_number for update, and description for create. The description itself adds no parameter detail, so the baseline 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 states the resource (Apps Script deployments) and enumerates the concrete operations: creating, updating, and deleting. This makes it clear what the tool does and implicitly distinguishes it from the read-only sibling list_deployments, though it never names 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 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: whenever deployments must be created, updated, or deleted. However, it gives no explicit guidance about when not to use it or which sibling to prefer, such as using list_deployments for read-only inspection or to obtain deployment_id values before update/delete.
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 simply restates the operations without adding behavioral context beyond the annotations, which already mark the tool as destructive and non-read-only. It does not disclose irreversibility, permission requirements, or what happens on duplicate filter creation.
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 short and front-loaded, with the second sentence adding specific operation detail. The first sentence is somewhat redundant with the tool name, but there is no wasted 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?
Combined with the well-documented schema and an existing output schema, the description is sufficient for correct invocation. The main missing piece is explicit usage routing, but the schema compensates for parameter-level guidance.
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%, with each parameter documented, so the baseline is 3. The description adds no additional parameter-level meaning beyond what the schema already provides.
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 identifies the resource (Gmail filters) and the specific actions (creating and deleting). It distinguishes itself from sibling tools like list_gmail_filters, though it doesn't explicitly name them.
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 conveys the tool's purpose—creating and deleting filters—so an agent knows when to invoke it. However, it provides no explicit guidance on when not to use it or how it relates to alternatives like list_gmail_filters.
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?
Annotations already disclose read-only, idempotent, open-world, and non-destructive behavior, so the bar is lower. The description adds scope context (searches personal contacts by name/email/phone) but leaves matching semantics and the ambiguous 'other fields' undefined. No contradiction with 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?
A single 10-word sentence with the verb front-loaded and zero wasted words. The description is appropriately sized for the tool's simplicity.
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 schema and annotations fully cover parameters and safety, and an output schema exists, so return values need no explanation. However, the description misses its key disambiguation role: given the large sibling set with several contact-related tools, an agent gets no help deciding between this and list_contacts or search_directory_people.
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 all three parameters are already fully documented in the schema. The tool description mostly echoes the query parameter description and adds only the vague 'other fields' extension.
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 states a specific verb (Search) and resource (contacts) with explicit searchable fields (name, email, phone number). It is clear and distinguishes itself from list_contacts and get_contact, though it doesn't explicitly differentiate from search_directory_people.
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. With close siblings like list_contacts, get_contact, and search_directory_people, an agent receives no help selecting the appropriate tool.
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?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the description does not need to cover those basics. It adds only 'new' to indicate a fresh resource is created, but provides no details on return values, side effects, or relationship to Google Drive. However, since an output schema exists and there is no contradiction with annotations, a mid-range score is appropriate.
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 sentence that conveys the essential action without filler. Every word earns its place, and the key verb and resource are 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?
For a simple two-parameter create tool with full schema coverage, an output schema, and meaningful annotations, the one-sentence description is largely sufficient. It lacks only occasional context such as that the resulting presentation will be stored in Google Drive, but this is not critical given the schema and annotations.
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%: both user_google_email and title have adequate schema descriptions. The tool description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 3 is correct.
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 states a specific verb ('Create') and resource ('a new Google Slides presentation'), making the core purpose clear. It does not explicitly differentiate from the sibling import_to_google_slides, which also results in a Slides presentation, so it falls short of full sibling distinction.
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 gives no guidance on when to use this tool versus alternatives such as import_to_google_slides or create_drive_file. There is no mention of prerequisites, when a new blank presentation is appropriate, or when another sibling would be a better choice.
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?
Annotations already indicate this is a non-read-only, non-idempotent, non-destructive operation. The description adds the key behavioral fact that it can either create a blank sheet or duplicate an existing sheet, which goes beyond the annotations. It does not describe side effects, copy behavior, naming conflicts, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one dense, front-loaded sentence followed by a compact signature. There is no filler, though the signature partially duplicates information already present in the schema.
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 tool with five parameters and zero schema descriptions, the description is adequate but lean: it states the core operation and lists all parameters, and an output schema exists so return values need not be described. Missing context includes when each optional parameter applies, how duplication differs from creating a blank sheet, and how this tool differs from create_spreadsheet.
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 description includes the full function signature, which helps identify all five parameters and their optionality, and the phrase 'duplicates an existing sheet' gives meaning to source_sheet_name. This partially compensates for the 0% schema description coverage, but there are no per-parameter explanations such as how insert_sheet_index behaves or the relationship between sheet_name and source_sheet_name.
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 states a clear action and resource: it creates a new sheet or duplicates an existing one, which is specific and not a tautology. It does not explicitly distinguish itself from the sibling create_spreadsheet, but the use of 'sheet' and the spreadsheet_id parameter make the target resource reasonably clear.
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 intended use case is implied by the phrasing: use this tool when a new sheet tab or a duplicate of an existing sheet is needed. However, there is no explicit guidance about when to prefer create_spreadsheet instead, nor any exclusions or alternative routing.
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?
Annotations fully cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), and the description's 'Retrieves' aligns with these without contradiction. However, the description adds no behavioral context beyond the annotations: it doesn't clarify what kind of content is returned (source code, file size limits, raw vs rendered), whether the file must belong to the given script project, or if authentication flows through user_google_email. Since annotations carry the burden and no contradiction exists, a mid-range score is appropriate.
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 tight sentence of eleven words, front-loaded with the action verb and resource. There is zero filler, and every word contributes to meaning. This is appropriately sized for a simple read operation.
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 (so return format is defined elsewhere), annotations fully declare the safety semantics, and the input schema covers all parameters at 100%, the description is nearly sufficient. The only minor gap is that it doesn't explicitly scope the tool to Apps Script project files or note that file_name refers to files within the script project. For a simple read-only tool with rich structured context, this is 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%, with all three parameters (user_google_email, script_id, file_name) already documented in the input schema. The description adds no parameter-level meaning, but the baseline of 3 applies because the schema does the heavy lifting and no compensation is needed.
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 uses a specific verb-resource pair ('Retrieves content of a specific file within a project') that naturally distinguishes it from siblings like get_script_project (metadata), list_script_projects (listing), update_script_content (mutation), and run_script_function (execution). It stops short of 5 because it doesn't explicitly state this concerns Apps Script source files (e.g., .gs/.html), which the agent must infer from the tool name and script_id parameter.
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?
There is no guidance on when to use this tool versus alternatives. Given a large sibling set including get_script_project, get_drive_file_content, get_doc_content, and run_script_function, the description provides no exclusions, prerequisites, or conditions for selection. An agent receives zero direction on choosing this over similar content-retrieval 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds context that the tool returns time-bucketed analytics, which is useful, but it does not disclose behavioral traits like what time range 'over time' spans, whether results are paginated, or whether prior authentication is required.
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 with zero wasted words. The main action is front-loaded ('Gets execution metrics for a script project'), and the second sentence justifies its place by describing what data the agent can expect, which aids tool selection.
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?
For a simple read-only tool, structured context is rich: an output schema exists, annotations cover the safety profile, and the schema fully documents parameters. The description adequately states purpose and return types; the only ambiguity is the unbounded 'over time' range, since no date-range parameter exists.
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%, with all three parameters (script_id, user_google_email, metrics_granularity) already documented in the input schema. The description adds no parameter-level semantics beyond the schema, so the baseline 3 applies.
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 states a specific verb and resource ('Gets execution metrics for a script project') and enumerates the returned data (active users, total executions, failed executions), making the tool's purpose unambiguous. Among the script-related siblings (get_script_project, list_script_processes), it is clearly the only analytics/metrics tool, though it never names a sibling explicitly to differentiate itself.
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?
There is no guidance on when to use this tool versus alternatives. With over 130 siblings including overlapping Apps Script tools like list_script_processes and get_script_project, the description offers no routing criteria, no exclusions, and no contextual trigger for when an agent should choose metrics over a process list or project details.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the description does not need to repeat safety details. It adds useful context by specifying that it fetches complete details including all source files. No contradiction with 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?
A single, front-loaded sentence with no filler. Every phrase ('complete project details', 'all source files') adds meaningful scope 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?
For a straightforward read operation with rich annotations, a full output schema, and fully described parameters, the definition is mostly complete. The main gap is explicit disambiguation from get_script_content and related script tools.
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?
Both parameters have descriptive entries in the schema, and schema description coverage is 100%. The description itself adds no additional parameter-level meaning, so the baseline of 3 applies.
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 states a specific action ('Retrieves') and a clear resource ('complete project details including all source files'), going beyond the tool name. It clearly conveys the basic function, though it does not explicitly differentiate itself from the similar sibling get_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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to choose this tool over get_script_content, list_script_projects, or other script-related siblings. The description only states what it returns, leaving the agent to infer the appropriate selection 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?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description is consistent with these and adds no additional behavioral context beyond what annotations convey.
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 with no filler or redundancy. It is appropriately sized for a simple read-by-ID tool.
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 is a simple single-resource read operation, and the output schema plus annotations cover most operational concerns. However, it does not mention how task_id is obtained or note any auth dependency, so completeness is strong but not maximal.
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 all three parameters are already documented in the schema. The description adds no parameter-level meaning or context.
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 states a clear verb and resource: 'Get details of a specific task.' The word 'specific' implies retrieval of a single task, distinguishing it from list_tasks, though it does not explicitly name sibling alternatives.
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 about when to use this tool versus list_tasks, manage_task, or get_task_list. There are no prerequisites, exclusions, or explicit routing to alternatives.
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?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond those annotations—no mention of error behavior, existence requirements, authentication needs, or how a missing version is handled.
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 six words and front-loaded with the key verb and resource. There is no filler, repetition of the title, or unnecessary detail that would dilute the message.
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?
For a simple get-by-identifier tool with a fully described input schema, comprehensive annotations, and an output schema present, the description is sufficient. The only minor gap is the lack of a pointer to list_versions for discovering version numbers, but this is not essential for correct invocation when the caller already knows the version.
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%, with all three parameters already described clearly (script_id, version_number, user_google_email). The description does not add extra parameter semantics, so the baseline score of 3 is appropriate since the schema carries the burden.
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 operation ('Gets details') and the resource ('a specific version'), which is more specific than a generic 'get version'. It does not explicitly differentiate itself from sibling tools like list_versions or create_version, but the phrase 'specific version' implies a single-object retrieval rather than enumeration or creation.
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 intended use is implied: retrieve details for one known version using its version_number. However, the description provides no explicit when-to-use guidance, no exclusions, and does not mention that list_versions should be used when version numbers need to be enumerated or when all versions are needed.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the core safety profile is covered. The description adds the behavioral detail that max_comments can limit the returned results, which is useful beyond the schema. It does not contradict the annotations, but it also does not disclose anything about pagination, reply inclusion, or comment ordering.
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 sentence with no filler, front-loading the action and resource before the optional parameter detail. Every word earns its place, and the parenthetical keeps the optional limit information out of the main clause.
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 read-only list tool with an output schema and strong safety annotations, the description is reasonably complete. However, it lacks guidance on tool selection and leaves the user_google_email parameter semantically unexplained. These are meaningful gaps, but not severe enough to make the tool unusable.
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 for the input schema's lack of explanations. It only adds meaning to max_comments by saying it limits results, and it implicitly maps spreadsheet_id to 'a Google Spreadsheet'. The required user_google_email parameter is completely unexplained, leaving the agent to infer its purpose from the name alone.
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 a clear verb and resource: 'List all comments from a Google Spreadsheet'. It distinguishes itself from sibling tools like list_document_comments and list_presentation_comments by explicitly naming the spreadsheet context. The optional max_comments parenthesis further clarifies the tool's scope.
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 gives no explicit guidance about when to use this tool versus alternatives such as manage_spreadsheet_comment or list_document_comments. It does not state any exclusions, prerequisites, or when to prefer a sibling tool. The only usage hint is the optional max_comments parameter, which is about result limiting rather than tool selection.
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?
Annotations already provide the safety profile (readOnlyHint=false, destructiveHint=true), and the description's mention of 'clear values' aligns with the destructive hint without adding substantive new behavioral context. It does add the scope specificity ('specific range') and the three modes, but it does not disclose overwrite semantics, irreversibility, or auth requirements beyond what the annotations imply. The bar is lower because of annotations, but the description still adds only modest 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 a single sentence with no filler, front-loading the core verb and resource before listing the modes. Every word earns its place, and it is appropriately sized for a tool whose schema is already self-documenting.
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 full schema coverage, the presence of an output schema, and annotations that declare destructiveness, the description covers the essential behavioral contract. It clearly states the operation scope and the three modes, which is sufficient for an agent to invoke the tool correctly in most cases. It is slightly terse for a 6-parameter mutation tool, but the missing details are all present in the structured fields.
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 per the rubric. The description's phrase 'write, update, or clear values' loosely maps to the values and clear_values parameters, but it does not clarify representation, defaults, or interpretation rules that the schema does not already cover. No additional parameter-level meaning is added.
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 states a specific verb ('Modifies') and resource ('values in a specific range of a Google Sheet'), and enumerates the three actions it can perform ('write, update, or clear values'). This is clear and non-tautological, and it implicitly distinguishes the tool from read-only siblings like read_sheet_values. However, it does not explicitly name a sibling or scope against alternatives such as append_table_rows, so it stops short of full differentiation.
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 gives no explicit guidance about when to use this tool versus alternatives, nor does it mention exclusions or related tools. The only usage signal is the verb 'Modifies', which is implied by the tool name rather than explained. The schema covers parameter-level conditions, but the description itself offers no decision support.
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?
Annotations already provide the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds the basic output scope ('free/busy information for a set of calendars'). However, it does not disclose limitations such as expansion caps, auth prerequisites, or the fact that detailed event data is not returned.
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 with no filler or redundancy. Every word contributes to the core meaning, and it is appropriately sized for the tool's simplicity.
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, complemented by a 100%-covered input schema and an output schema, is sufficient for an agent to invoke the tool correctly. The only notable gap is the absence of usage guidance versus sibling tools, but that is already captured in the usage dimension.
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 input schema fully documents all six parameters including defaults, formats, and maximum values. The description adds no parameter-level meaning beyond what the schema already provides, so baseline 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 uses a specific verb ('Returns') and resource ('free/busy information for a set of calendars'), making the core purpose clear. It does not explicitly differentiate itself from siblings like get_events, so it misses the top score.
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 gives no guidance about when to use this tool versus alternatives such as get_events or list_calendars. There is no mention of availability checking, exclusions, or conditions that would select this tool.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is fully covered. The description adds a useful scope constraint ('for the authenticated user') but does not disclose behavioral details such as pagination iteration or whether all contact groups are included. No contradiction with 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?
A single seven-word sentence that front-loads the verb and resource and contains zero filler. Nothing is repeated from the schema or annotations, and every word earns its place.
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 read-only tool, the structured data covers a lot: the output schema explains return values, the schema covers parameters, and the annotations cover safety. The main gap is that with search_contacts, get_contact, and list_contact_groups as siblings, the description does not clarify exactly what subset of contacts is returned or when listing should be chosen over searching.
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 fully documents all four parameters (page_size, page_token, sort_order, user_google_email). The description's phrase 'authenticated user' slightly reinforces that user_google_email is the token holder's email, but this is marginal value beyond what the schema already states. Baseline 3 applies.
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 uses a specific verb ('List') and a clear resource ('contacts'), scoped to 'the authenticated user.' This distinguishes it from mutating tools like manage_contact and single-item tools like get_contact, though it does not explicitly name or contrast any sibling such as search_contacts.
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?
Usage context is implied rather than stated: call this when you need the authenticated user's own contact list. However, there is no explicit guidance on when to prefer it over search_contacts (broader search) or get_contact (single contact), and no exclusions or alternative conditions 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?
Annotations already establish readOnlyHint=false and destructiveHint=true, and the description's 'delete' action is consistent with that safety profile — no contradiction exists. The description adds only concrete outcomes (create/update/delete) but no nuance such as system labels being undeletable, whether update is partial or full replacement, or failure behavior. Since annotations carry the safety load, the description contributes minimal additional behavioral context beyond what is already structured.
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 10-word sentence, front-loaded with the verb+resource pair and followed by a colon-enumerated operation list. Every word contributes, with only a trivial repetition of 'labels' in the enumeration. It is highly scannable in a sibling list of over 130 tools.
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?
Moderate complexity — 6 parameters, 3 operation modes with distinct parameter requirements, and destructive potential — is substantially covered by the 100%-coverage schema, the presence of an output schema, and the safety annotations. What remains for the description is selection guidance and behavioral nuance, which is thin: no sibling routing and no disclosure of edge cases like system-label restrictions. This is adequate as a minimum viable definition but leaves clear 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 100%, and the schema itself documents conditional requirements ('Label name. Required for create, optional for update' and 'Label ID. Required for update and delete operations') as well as enum defaults for the visibility parameters. The description adds no parameter-level meaning beyond restating the action enum already present in the schema. The baseline of 3 applies because 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 identifies the resource (Gmail labels) and enumerates the full operation set ('create, update, or delete'), making the tool's scope unambiguous. The action set implicitly separates it from read-only sibling list_gmail_labels and from modify_gmail_message_labels, which operates on message-label assignments rather than label definitions. However, it never explicitly names exclusions or sibling alternatives, so differentiation is inferred rather than stated.
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 operation set implies the tool's use cases — creating, updating, or deleting label definitions — giving an agent a reasonable heuristic for selection. The description provides no explicit when-to-use guidance, no exclusions, and does not route the agent to list_gmail_labels for read-only viewing or to modify_gmail_message_labels for attaching labels to messages. This is implied usage at best, with no alternatives or conditionals stated.
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?
Annotations already declare this as a non-read-only, non-idempotent, non-destructive external write, and the description aligns with those hints. The description adds no extra behavioral context such as duplicate-calendar side effects or permission requirements, but the structured annotations carry enough of that burden to make the gap moderate rather than severe.
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 one short sentence with no filler, starts with the operative verb, and states the core resource and scope immediately. Every word earns its place, and nothing is redundant with the tool name or title.
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?
For a simple scalar-parameter create operation with full schema coverage and an output schema, this description is nearly sufficient for correct invocation. The main missing elements are usage context and side-effect nuance, but those are partly addressed by annotations and do not block an agent from calling 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?
The schema documents all four parameters with descriptions and defaults, so the 100% schema coverage means the description does not need to compensate. The description adds no parameter-specific nuance, so the schema-driven 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 names a specific action ('Creates') and a specific resource ('a new secondary Google Calendar'), which clearly distinguishes it from list_calendars or event-management tools. The word 'secondary' adds important scope by indicating this tool does not create or modify the primary calendar.
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 gives no guidance on when to use this tool versus alternatives such as list_calendars or manage_event. It also does not mention prerequisites like Google authentication or any exclusions beyond the word 'secondary', leaving the agent to infer usage context from the tool name and sibling list.
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?
Annotations already convey that this is a mutating, non-idempotent, non-destructive operation, so the description only needs to add context beyond that. It does add useful behavior about shared drives and accepted content sources, but it omits potential side effects such as server-side URL fetching from fileUrl or required authorization state.
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 tightly written sentences with no filler. The primary action and resource are front-loaded, followed by the two most decision-relevant behaviors: shared drive support and accepted content input formats.
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?
For an 8-parameter tool, the schema carries most of the parameter details and output schema is present, so the description need not enumerate every field. It covers the core operation, shared drive capability, and content input modes. A minor gap is that it does not state whether content inputs are mutually exclusive or how conflicts are handled, but the schema's descriptions largely compensate.
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 eight parameters. The description's mention of 'direct text content, inline base64 bytes, or a fileUrl' summarizes the schema's content, base64_content, and fileUrl parameters without adding new parameter-level meaning 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 action ('Creates a new file in Google Drive') and the specific resource, while adding meaningful scope details: shared drive support and three content source modes. This distinguishes it from related tools like create_drive_folder and update_drive_file without needing to inspect the schema.
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 explicit guidance is given about when to use this tool versus alternatives such as import_to_google_doc, import_to_google_sheets, copy_drive_file, or create_drive_folder. The agent must infer selection from the tool name and the first verb rather than from any stated conditions or exclusions.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no extra behavioral context, such as authentication needs or error behavior, but it also does not contradict the 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 a single concise sentence that immediately states the action and resource. Every word earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool, the combination of a complete input schema, a true output schema, and safety annotations covers most of what an agent needs. The description is minimal but sufficient, though it does not mention how to obtain the contact_id (e.g., via list_contacts).
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 both parameters are already well-documented in the input schema. The description does not add additional semantic meaning beyond the implicit 'specific contact' reference, which aligns with contact_id.
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 'Get detailed information about a specific contact' clearly identifies a read operation for a single contact, using a specific verb and resource. It is distinct from sibling tools like list_contacts or search_contacts because it targets a specific contact, though it does not explicitly name any sibling.
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 phrase 'a specific contact' implies this tool should be used when a contact_id is already known, providing minimal usage context. However, it does not mention alternatives or conditions for choosing between get_contact, search_contacts, or list_contacts, so the guidance is only implied rather than explicit.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the scoping detail that all labels are returned, but does not mention auth prerequisites or return behavior 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?
Single sentence of eight words with no wasted verbiage. The essential information is front-loaded and every word contributes to the meaning.
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 is simple with one required parameter, an output schema, and annotations that cover safety. The description adequately states the operation scope; only sibling differentiation is omitted, which is more a usage-guideline concern than a completeness gap.
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%; the parameter user_google_email is fully described in the schema with its type and required status. The tool description adds no additional parameter-level meaning, so the baseline of 3 applies.
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?
States the specific verb 'Lists,' the resource 'all labels,' and the scope 'in the user's Gmail account.' This clearly differentiates it from message search tools and label-management tools like manage_gmail_label.
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 explicit guidance on when to use this tool versus alternatives such as list_gmail_filters or manage_gmail_label. Usage is only implied by the tool's name and basic purpose, not articulated.
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?
The description adds useful behavior beyond the annotations by mentioning the optional max_comments limit. However, the read-only, idempotent nature is already covered by annotations, and the description does not clarify subtleties like whether resolved comments or replies are included. 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?
The description is a single front-loaded sentence with no redundant phrasing. Every element earns its place: the resource, the action, and the optional limiting parameter.
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?
For a simple read-only listing tool with annotations and an output schema, this definition is nearly complete. It clearly states what the tool returns and the optional limit. It lacks only explicit context about alternative comment tools and details like comment types or reply handling, but those are not required for basic 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 schema has no parameter descriptions, so the description partially compensates by explaining max_comments as an optional limiter and by identifying the target resource as a Google Presentation for presentation_id. However, user_google_email is left to be inferred from its name, and no format or source guidance is provided. Partial compensation is present but not complete.
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 a specific action ('List all comments') and a specific resource ('from a Google Presentation'), which clearly distinguishes it from sibling tools like list_document_comments and list_spreadsheet_comments. It also conveys the optional limiting behavior via max_comments. This is exact 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives such as manage_presentation_comment, list_document_comments, or list_spreadsheet_comments. The resource scope is implied, but the description does not say when to prefer this tool or when to avoid 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?
Annotations already declare destructiveHint=true and readOnlyHint=false, and the description is consistent with them. The description adds that deletion is one of the operations, which helps identify a destructive path, but it does not disclose effects such as tab-content replacement or the irreversibility of deletion beyond what the schema's replace_existing parameter already says. This is moderate disclosure beyond annotations 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?
The description is a single sentence that front-loads the resource and then lists all supported operations with zero filler. Every word contributes to understanding the tool's 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 a rich schema covering 100% of parameters, an output schema, and annotations signaling destructive behavior, the tool is adequately specified for invocation. The description could still add a sentence about when to choose this tool over other document-manipulation siblings, which prevents a perfect score.
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 of 3 applies; all nine parameters have descriptions, including per-action requirements and the action enum. The description adds only the high-level 'populate from Markdown' concept, which maps to markdown_text but adds little 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 identifies document tabs as the resource and enumerates the four supported operations: create, rename, delete, and populate from Markdown. This is more specific than the generic title. It does not explicitly differentiate from sibling doc-editing tools, but the tab-specific resource and 'populate from Markdown' make 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The action list implies the tool is for document-tab lifecycle operations, and the schema directs agents to use inspect_doc_structure for tab IDs. However, the description itself provides no explicit when-to-use or when-not-to-use guidance and names no alternative tools. The intended scope is inferable rather than stated.
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?
Annotations already convey readOnlyHint=false and destructiveHint=true, so the description does not need to restate mutation. It adds useful behavioral context by explaining that these events auto-decline invitations and set the user's status. However, it does not address consequences of update/delete actions, though annotations partially cover this.
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 tight sentences with no filler. The first sentence names the resource and the second explains what makes OOO events special. Every word earns its place.
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?
For a 14-parameter tool with multiple actions, the description is minimal, but the input schema fully documents every parameter and an output schema exists. Annotations also flag mutability. The main gap is explicit routing versus sibling calendar tools, which is already captured in the usage_guidelines score.
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 description contains no parameter-level detail, but schema_description_coverage is 100%, meaning every parameter already has semantic documentation. With the schema carrying that weight, a 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 identifies the resource as 'Out of Office events on Google Calendar' and adds distinguishing behavior: auto-declining invitations and setting Workspace status. The verb 'Manages' is somewhat generic, but the specific resource and domain semantics make the tool's purpose evident.
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 use case by explaining that OOO events are special auto-declining/status-setting events, but it never explicitly says when to prefer this tool over siblings like manage_event or manage_focus_time. No alternatives or exclusions are named.
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?
Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already cover the safety profile, and the description is consistent with them, adding no contradiction. The description itself adds no behavioral context beyond the annotations, though the schema parameter descriptions do disclose meaningful traits (1000-row range clamping, expensive includeGridData requests for notes/hyperlinks, extra API call for formulas). With annotations carrying the safety burden, a 3 is appropriate.
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 ten-word sentence that front-loads the verb and object. Every word earns its place and nothing is redundant with the schema or annotations.
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?
For a read-only tool with a rich 100%-covered schema, an output schema, and safety annotations, the one-line description is sufficient to complete the picture. The only minor gap is that it does not orient the agent between this tool and get_spreadsheet_info for structural/metadata reads, but the name and schema largely compensate.
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 fully documents all six parameters with examples, defaults, and cost rationale (e.g., 'Defaults to False to avoid expensive includeGridData requests'). The description text adds no parameter meaning beyond the schema, so the baseline 3 applies.
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 a specific verb ('reads') and resource ('values from a specific range in a Google Sheet'), which clearly identifies the tool's function. It is self-evidently distinct from the closest sibling, modify_sheet_values (the write counterpart), and from get_spreadsheet_info (metadata, not cell values), even without naming them.
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 when-to-use guidance, exclusions, or named alternatives. Usage is only implied by the tool name and the presence of modify_sheet_values as an obvious write counterpart. The schema's include_formulas parameter hints at a pre-write use case ('before writing back to a range'), but the description itself carries no routing 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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds scope detail by mentioning shared drives and file/folder results, but does not disclose further behavioral traits like query edge cases or pagination 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?
A single front-loaded sentence that states the verb, resource, and scope with no filler or redundancy. It is appropriately concise for a tool whose parameter details live in the schema.
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 is complex with 11 parameters, but the input schema thoroughly documents each one, including useful caveats like shared-drive owner query limitations. The output schema and annotations cover return values and safety. The only notable gap is the lack of explicit routing guidance versus sibling Drive tools like list_drive_items.
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 burden on the top-level description is low. Parameter descriptions already document query operators, defaults, corpora behavior, MIME types, pagination, and trash handling. The top-level description adds only minimal context about files/folders and shared drives.
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?
States a specific verb ('Searches') and resource ('files and folders within a user's Google Drive, including shared drives'). This clearly separates it from Gmail search, file content retrieval, and Drive listing 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?
No explicit guidance on when to use this tool versus alternatives like list_drive_items or search_gmail_messages. The intended usage is only implied by the word 'Searches,' with no mention of when to prefer or avoid this tool.
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?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds that search is by text content and/or time range but does not disclose cross-space search behavior, pagination, or result limits beyond what the schema already lists. No contradiction with 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 a single, front-loaded sentence with no filler or redundancy. It clearly states the action, resource, and search dimensions in minimal space.
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 rich parameter schema, output schema, and annotations, the one-line description is mostly sufficient for an agent to invoke the tool correctly. The only notable gap is that it does not explicitly mention cross-space search behavior when space_id is omitted, but the max_spaces parameter description largely covers that.
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 high (83%), with detailed documentation for query, space_id, page_size, max_spaces, and time_filter. The description adds little parameter-level meaning beyond naming the text-content and time-range search modes, so the 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 uses a specific verb ('Searches'), a clear resource ('messages in Google Chat spaces'), and explicit scoping ('by text content and/or time range'). This distinguishes it from siblings like search_gmail_messages and get_messages without requiring schema inspection.
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 gives no guidance on when to use this tool versus alternatives such as get_messages or search_gmail_messages. There are no explicit exclusions or routing hints, so an agent must infer the right context from the tool name and schema.
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?
Annotations already indicate this is a destructive, non-read-only operation, and the description matches that without contradicting it. The description adds the useful behavioral detail that this is a single batch request, but it does not disclose nuances like partial failure behavior or what happens if only message_ids are provided with no label changes.
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 sentence with no fluff or repetition of schema details. It front-loads the core action and the distinguishing batch characteristic efficiently.
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?
With full schema descriptions, an output schema, and annotations covering mutability/destructiveness, the description is minimally sufficient. However, it could be more complete by explicitly signaling the singular sibling tool and clarifying batch behavior when add and remove arrays are both supplied.
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 each parameter already has a clear description. The tool description does not add additional meaning about parameter relationships, such as whether add_label_ids and remove_label_ids can be used simultaneously or whether at least one is expected.
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 a specific verb ('Adds or removes'), a clear resource ('labels from multiple Gmail messages'), and a distinguishing mode ('in a single batch request'). This makes it easy to tell apart from the singular sibling tool 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'multiple Gmail messages' and 'single batch request' imply that this tool is for bulk label modifications, but it does not explicitly say when to prefer it over modify_gmail_message_labels or mention any exclusions. Usage context is only implied, not stated.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about what metadata categories are returned, but it does not disclose any additional behavioral traits such as auth requirements or rate limits. No contradiction 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?
The description is a single, focused sentence that front-loads the action and resource, then lists relevant metadata categories. There is no filler or redundant phrasing.
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?
This is a low-complexity, read-only tool with only two documented parameters, rich annotations, and an output schema. The description sufficiently covers what the agent needs to know to select and invoke it correctly. Additional sibling differentiation would improve it, but that gap is already captured in the usage dimension.
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 both parameters (file_id, user_google_email) are already documented clearly in the schema. The description adds no additional parameter-level meaning, so the 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 uses a specific verb ('Gets') with a clear resource ('detailed metadata about a Google Drive file') and enumerates concrete content categories: sharing permissions, parent folder IDs, ownership, and lifecycle timestamps. This distinguishes it from siblings like set_drive_file_permissions, which perform writes, and check_drive_file_public_access, which is narrowly scoped.
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 explicit guidance is given about when to use this tool versus related siblings such as check_drive_file_public_access, get_drive_shareable_link, or manage_drive_access. The usage context is only implied by the description, with no exclusions or alternative routing.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds meaningful behavior beyond this: include_speaker_notes returns each slide's speaker notes and the object ID of the shape holding them, and that shape ID is the only valid target for note edits. This is useful cross-tool context that annotations do not provide.
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 main description is a single, focused sentence. The longer explanation is placed inside the parameter description where it is directly relevant, and every sentence there adds operational value rather than repeating schema 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?
With output schema present, annotations covering the read-only safety profile, and full parameter schema coverage, the description is nearly complete for a simple read tool. The main gap is not explaining when to use get_page or other presentation-related tools, but the available context signals largely compensate.
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 baseline is 3. The include_speaker_notes parameter description adds significant meaning by explaining what the flag returns and why the returned shape ID matters for later note edits. The other two parameters are already self-explanatory in 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 states a clear verb and resource: get details about a Google Slides presentation. It is distinguishable from sibling tools like get_page and get_page_thumbnail because it targets the presentation-level object, though 'details' is somewhat generic and does not specify what is returned.
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?
There is no explicit guidance on when to use this tool versus alternatives, and no exclusions are stated. The only usage hint is buried in the include_speaker_notes parameter, which explains when to pass True, but the tool-level description does not help an agent choose between it and related presentation/page 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?
Annotations already signal a mutating operation (readOnlyHint=false), and the description clarifies insertion of an image from Drive/URL without contradicting the annotations. It does not add deeper behavioral context such as content shifting at the insertion index or authentication dependences on user_google_email.
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 with no filler, and it conveys the essential purpose and accepted source types efficiently.
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 insertion tool this is close to adequate: schema covers parameters and an output schema is present. However, it omits guidance on choosing this over insert_doc_elements and any preconditions around Drive/URL access, so an agent relying solely on the description could still choose or invoke it incorrectly.
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 explains all six parameters. The description adds no parameter-level meaning beyond restating the image source types already covered by image_source.
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 names a specific action, object, destination, and source: 'Inserts an image into a Google Doc from Drive or a URL.' This clearly distinguishes it from text-modification tools like modify_doc_text and broader element tools like 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied by the verb ('inserts an image') and the schema's document/image parameters, but the description gives no explicit when-to-use or when-not-to-use guidance. It does not compare against insert_doc_elements or state prerequisites like Drive sharing permissions.
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?
Annotations already convey that this is a mutating, destructive operation. The description adds specificity by naming revoke and transfer_owner, which are the destructive actions, but it does not disclose side effects, reversibility, or notification behavior beyond what the schema already documents.
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-loads the tool's purpose, and contains no filler. Every sentence contributes to understanding what the tool does.
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 14-parameter tool with five action branches, the description is somewhat lean, but the input schema richly documents each parameter and the output schema handles return values. The main gap is unresolved overlap with the sibling set_drive_file_permissions tool, which prevents a higher completeness score.
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%, with each parameter individually documented in the input schema. The description adds no parameter-level detail beyond the schema, so the 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 identifies the resource (Google Drive file and folder access permissions) and enumerates the supported operations: granting, batch-granting, updating, revoking permissions, and transferring ownership. It is specific about scope, though it does not explicitly differentiate from the sibling set_drive_file_permissions 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?
The phrasing 'Consolidated tool' and 'all through a single entry point' gives clear context that this is the intended hub for permission management. However, it does not name alternatives or state when to use get_drive_file_permissions or set_drive_file_permissions instead, so exclusion guidance is missing.
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?
Annotations already carry destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is disclosed structurally. The description adds no behavioral context beyond 'executes a function' and does not warn that arbitrary Apps Script code may have side effects, though this is also covered by the annotations. There is no contradiction with the 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 a single, grammatically complete sentence with no filler. It states the core action immediately and avoids redundancy with the schema or annotations.
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 schema, annotations, and output schema cover parameters, side-effect risk, and return format, so the tool is callable. However, the description is sparse: it omits any guidance about required deployment state, the fact that dev_mode can run undeployed code, and potential side effects beyond what annotations imply. A slightly richer description would improve agent confidence.
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 every parameter, including dev_mode, parameters, function_name, script_id, and user_google_email. The description adds no parameter-specific meaning, but none is needed given the complete 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 a specific verb ('Executes') and a clear resource ('a function in a deployed script'). Among the many script-management siblings, this is the only direct execution tool, so it is easily distinguished from list_script_projects, get_script_content, and manage_deployment.
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 use case is implied by the title and description: invoke an Apps Script function by script ID, function name, and user email. However, the description does not explicitly say when to use this instead of alternatives like generate_trigger_code or manage_deployment, nor does it mention prerequisites such as an existing deployment.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the search is performed by file name rather than ID, but it does not disclose additional behavioral nuance such as what counts as 'public link sharing', how the user email is used, or whether only the first match is evaluated. No contradiction with annotations 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?
The description is a single, front-loaded sentence with no filler. It communicates the essential action and outcome immediately, and every word contributes to the tool's 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?
Given the strong annotations, 100% schema coverage, and the presence of an output schema, the description covers the core intent well. The only notable gap is the potential ambiguity around what exactly qualifies as 'public link sharing' and whether the tool returns a simple boolean or detailed sharing information, but the output schema likely addresses the return format.
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%, including a notably detailed explanation of the drive_id parameter and its effect on the underlying files.list call. The description itself adds no new parameter-level meaning beyond restating that the tool searches by file name and inspects public link sharing, so the schema carries the load.
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 a specific verb and resource: 'Searches for a file by name and checks if it has public link sharing enabled.' This clearly distinguishes it from siblings like get_drive_file_permissions or get_drive_shareable_link, since the focus is specifically on detecting public link sharing rather than listing permissions or retrieving links.
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 usage context: use this tool when you need to verify whether a file is publicly shareable via link. However, it does not explicitly state when not to use it or name alternatives such as get_drive_file_permissions or get_drive_shareable_link, leaving the routing decision to the agent's inference.
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?
Annotations already indicate this is a non-read-only, non-idempotent, non-destructive operation, and the description aligns with that. However, the description adds no extra behavioral context beyond the core action, such as the reaction being publicly visible to space members, duplicate-reaction behavior, or any authorization requirements. It is adequate but not informative beyond the 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 a single sentence that immediately states the action and target. Every word contributes value and there is no filler or repetition of the title.
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 tool is simple and an output schema exists, so the description does not need to cover return values. However, the required user_google_email parameter is left ambiguous in both the schema and the description, and no usage context (e.g., acting as a specific user or needing space membership) is provided. The description is minimally viable but has clear gaps.
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 schema describes message_id and emoji_unicode, but user_google_email has no schema description. The tool description does not explain any parameters or compensate for the undocumented required field. Since schema coverage is only 67% and the description adds no param-level meaning, the agent is left to guess the role of user_google_email.
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 a specific verb ('Adds') with a specific resource ('emoji reaction') and target ('Google Chat message'). It is immediately clear what the tool does and it distinguishes itself from all sibling tools, none of which mention reactions.
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 context: the tool is for adding an emoji reaction to a Chat message. No sibling tool performs this action, so no exclusions or alternatives need to be named. It falls short of a 5 only because it does not explicitly state when not to use it or mention related Chat tools.
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 annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds valuable behavioral context by stating 'This permanently deletes the script project. The action cannot be undone.' This reinforces the irreversibility in a way the annotations do not fully convey. No contradiction 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?
The description is two short sentences, with the core action first and the critical permanent-deletion warning second. Every sentence earns its place, and there is no filler or redundant detail.
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?
For a simple two-parameter destructive tool with output schema, annotations, and full schema coverage, the description covers the essential irreversible nature of the operation. It is slightly incomplete because it does not mention when deletion should be used or what happens to related resources, but these are largely covered by the annotations and clear purpose.
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%, with both script_id and user_google_email already documented in the input schema. The description adds no additional parameter-level meaning, but it does not need to because the schema covers the parameters adequately. 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 states a specific verb and resource: 'Deletes an Apps Script project.' It further clarifies that the deletion is permanent, which clearly distinguishes this destructive tool from sibling tools like list_script_projects, get_script_project, create_script_project, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives, when deletion is appropriate, or what prerequisites apply. It only restates the action itself and its irreversibility. There is no explicit or implicit comparison to 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?
Annotations already convey the safety profile (readOnlyHint=false means write, destructiveHint=false means no destruction, idempotentHint=false means repeated calls create separate drafts). The description adds useful capability context beyond the annotations — supports reply drafts, optional attachments, and Send As aliases — but does not disclose behavioral traits such as where the draft lands (Drafts folder), whether signature insertion has side effects, or what happens on partial failure. The description does not contradict the 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 short sentences, each earning its place: core purpose first, then scope expansion (new/reply drafts, attachments), then the Send As differentiator. No redundancy, no filler, and the most decisive information is 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?
For a 15-parameter tool, the schema documents every parameter fully and an output schema exists, so the description's burden is light. It adequately covers the tool's major decision points (drafting vs replying, attachments, aliases). The only gap is the absence of an explicit draft-vs-send routing statement, which is a minor omission given the tool name and sibling set make the boundary clear.
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 references optional attachments and Send As, which map to the 'attachments' and 'from_email' params, but adds no parameter-level detail beyond what the schema already provides — and the schema's param descriptions (especially for attachments) are already very rich.
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?
"Creates a draft email in the user's Gmail account" is a specific verb+resource statement. The term "draft" cleanly separates it from the sibling send_gmail_message, and the mention of reply drafts and Send As capability adds further specificity. An agent can tell what this tool does without opening the schema.
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?
Usage context is implied rather than stated: the tool is for creating drafts, which by implication is distinct from sending (send_gmail_message) or reading (search_gmail_messages, get_gmail_message_content). However, no sibling is explicitly named, no when-not-to-use conditions are given, and no guidance is provided for choosing between 'new draft' vs 'reply draft' paths.
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?
Annotations already signal a non-read-only, non-idempotent, non-destructive operation. The description adds that the result is saved to Google Drive, which clarifies the output location, but it does not disclose prerequisites, permission requirements, or duplicate/overwrite behavior. This is acceptable 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?
The description is a single, front-loaded sentence with no filler. Every word contributes: the action, the source format, the target format, and the destination are all included efficiently.
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?
For a relatively simple conversion tool, the description, full parameter schema, annotations, and existing output schema provide enough information for an agent to call it correctly. It is slightly incomplete only in not addressing edge cases like file naming defaults or authorization context, but those are covered elsewhere or are non-essential.
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 describes all four parameters with 100% coverage. The description does not add parameter-level meaning beyond aligning document_id with the source doc and folder_id with the Drive destination, so the 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 states a specific verb ('Exports') and resource ('Google Doc to PDF format'), and also notes the output destination ('saves it to Google Drive'). This is distinguishable from siblings such as get_doc_as_markdown or copy_drive_file, none of which perform PDF conversion.
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?
Usage is implied: use this when you need a PDF version of a Google Doc saved to Drive. However, the description provides no explicit when-to-use guidance, no exclusions, and does not name alternatives such as get_doc_as_markdown or get_drive_file_download_url.
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?
Annotations already disclose read-only, idempotent, and non-destructive behavior, so the description does not need to repeat safety traits. It adds the useful detail that members are returned, but it does not describe pagination limits or other behavioral nuances beyond what the schema already conveys.
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 that delivers the core purpose without filler. It is appropriately sized for a simple read operation and front-loads the key idea.
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 is simple, has full schema coverage, a rich set of annotations, and an output schema, so the description is largely sufficient. The only minor gap is the absence of explicit guidance about how this differs from list_group_members.
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 needs to add little about parameters. The description does not elaborate on group_id, max_members, or user_google_email, but the schema already documents these fully.
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 ('Get details') and the resource ('a specific contact group'), and it explicitly calls out that members are included. This distinguishes it from list_contact_groups and list_group_members in the sibling set, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for retrieving a single group by ID, especially with required 'group_id', but it does not explicitly say when to choose this over list_contact_groups or list_group_members. No exclusions or alternatives are mentioned.
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?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds meaningful context about the 25-thread batch limit and the underlying reason (preventing SSL connection exhaustion), which is not present in annotations and helps the agent respect rate/connection constraints.
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 short sentences: the first states the core purpose, the second states the key limit and rationale. Every word earns its place, 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?
With a full input schema, an output schema present, and annotations covering side-effect safety, the call context is largely complete. The only notable gap is explicit guidance on when to use this tool versus related single/batch thread or message tools.
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%, including descriptions of thread_ids, body_format, and user_google_email. The description adds no parameter-level semantics beyond what the schema already provides, so it stays at the 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 states a specific verb ('Retrieves'), a specific resource ('multiple Gmail threads'), and the batching scope ('in a single batch request'). This clearly differentiates it from single-thread retrieval and message-batch retrieval by resource type and batch behavior.
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 gives a constraint (up to 25 threads per batch) but no explicit guidance on when to choose this tool over get_gmail_thread_content or get_gmail_messages_content_batch. It leaves usage selection to inference from the tool name rather than stating conditions or 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?
The annotations already indicate readOnly, openWorld, idempotent, and non-destructive behavior, so the description does not need to restate safety. It adds value by clarifying that the listing is scoped to the authenticated user, which is meaningful context beyond the structured annotations. The output schema covers return details, reducing the need for further description.
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 that directly states the tool's function without any filler. It is front-loaded with the action and resource, making it easy for an agent to quickly grasp the purpose. Every word contributes meaning.
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?
For a simple list operation with one required parameter, full schema coverage, and an output schema, the description is largely sufficient. It correctly identifies the resource and the scope of results. It could be slightly more complete by noting any pagination or ordering behavior, but given the strong annotations and schema support, no critical information is missing.
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, with user_google_email clearly described as the user's Google email address and required. The tool description adds no additional semantic detail about the parameter beyond what the schema already provides. The baseline score of 3 is appropriate when the schema carries the full documentation load.
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 action ('Retrieves a list') and resource ('calendars'), using a specific verb and object. It also adds a scoping detail ('accessible to the authenticated user'). However, it does not explicitly differentiate itself from sibling tools like create_calendar, though the verb and noun make the distinction reasonably clear.
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 that this tool is for listing existing calendars, which indirectly distinguishes it from create_calendar and event-focused tools. There is no explicit guidance on when to choose this over alternatives, nor any mention of prerequisites like authentication state. The usage context is only implied by the nature of the operation.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the scope 'all filters in the user's mailbox' but does not provide extra behavioral context such as pagination, ordering, or auth prerequisites.
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, focused sentence with no filler. It is front-loaded with the verb and resource and does not waste tokens.
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 simple one-parameter schema, the presence of an output schema, and rich annotations, the description is largely complete for correct invocation. It could be more complete by noting any required auth prerequisite, but this is a minor gap.
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 user_google_email is already well documented in the schema. The tool description adds no additional parameter meaning, which is acceptable per baseline but not enhancing.
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 ('Lists') and a clear resource ('all Gmail filters configured in the user's mailbox'). It cleanly distinguishes this from sibling tools like list_gmail_labels and manage_gmail_filter.
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 intended use is implied: call this tool when you need to see the Gmail filters for a user. However, it does not explicitly state when to avoid it or mention any alternative, such as using manage_gmail_filter to create/update filters.
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?
Annotations already provide readOnlyHint, idempotentHint, openWorldHint, and destructiveHint. The description adds the implementation detail 'Uses Drive API to find Apps Script files' and the scope 'accessible to the user,' but nothing beyond that. No contradiction with 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?
Two short sentences, front-loaded with the core purpose and followed by a one-line implementation note. No unnecessary detail, perfectly sized for a simple list operation.
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?
For a read-only list tool with full parameter descriptions, robust annotations, and an output schema, the description covers the essential purpose and scope. Pagination is implied by page_token/page_size, so no critical information is missing, though a brief note on result ordering or returned fields would make it fully 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% and all three parameters (page_size, page_token, user_google_email) are well-described. The tool description adds no parameter-specific meaning beyond what the schema already provides, 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 the specific action and resource: 'Lists Google Apps Script projects accessible to the user.' This distinguishes it from sibling tools like list_drive_items, list_script_processes, and get_script_project without requiring the reader to inspect schemas.
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 enumerate Apps Script projects) but does not explicitly state when to prefer alternatives or when not to use it. No guidance on exclusions or comparison with related list tools like list_drive_items.
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?
Annotations already indicate destructive and non-read-only behavior. The description adds that deletion is supported and that the tool consolidates add/update/delete operations, but it does not disclose side effects, auth requirements, or action-specific consequences beyond what annotations provide.
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 short sentences with no filler. The first sentence establishes the resource and the second enumerates the operations, making the purpose immediately clear 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?
For a tool with 11 parameters and three distinct actions, the schema carries the detailed operational load very well, and an output schema exists so return-value explanation is unnecessary. The description could add a brief usage-selection note, but combined with the rich schema it is largely sufficient for correct 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%, and each parameter description already documents action-specific requirements such as rule_index being required for update/delete and range_name being required for add. The tool description itself adds no parameter-level meaning, so the 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 names a specific resource—conditional formatting rules on a Google Sheet—and clearly enumerates the supported operations: adding, updating, and deleting. This distinguishes it from general formatting tools like format_sheet_range and avoids being a mere restatement of the tool name.
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 use case by focusing on conditional formatting rules, but it never explicitly says when to prefer this tool over alternatives or when not to use it. It states what the tool does but provides no exclusions or sibling-tool comparisons.
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?
Annotations already declare destructiveHint=true, readOnly=false, and idempotent=false, and the description's create/update/delete verbs are consistent with those hints. The description adds no deeper behavioral detail such as merge semantics, read-modify-write behavior, or prerequisites for update/delete, but it does not contradict the 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 a single front-loaded sentence with no filler. The first clause states the core action, and the second clause justifies why this tool exists, earning its place without bloating the definition.
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 very rich input schema, output schema presence, and annotations, the description does not need to enumerate parameters or return behavior. The only minor gap is the lack of an explicit pointer to manage_contacts_batch for multi-contact operations, but the schema and annotations otherwise make the tool sufficiently 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?
With 100% schema description coverage, the schema already documents all 26 parameters in detail, including action-specific requirements and mode semantics. The description itself contributes no additional parameter-level meaning, so it stays at the coverage 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's verb-resource scope: 'Create, update, or delete a contact.' It also frames the tool as a consolidated replacement for three legacy tools, making its role in the API unambiguous and easy to distinguish from read-only or batch-oriented contact 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 gives useful context by naming the three tools it replaces, which implies this is the single-contact CRUD entry point. However, it does not explicitly address when to use this tool versus sibling manage_contacts_batch or other contact-related tools, leaving the batch-vs-single decision implicit.
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?
Beyond the annotations, the description adds valuable behavioral context: Focus Time events auto-decline meeting invitations and, by default, set chat status to Do Not Disturb. These side effects are not obvious from the tool name alone and help the agent understand the real-world impact of creating such an event. The destructiveHint annotation is not contradicted by the description.
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 focused sentences front-load the core purpose and the key behavioral consequences. No filler or repetition of schema details.
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 schema and output schema cover the parameter and return details, and the description covers the behavioral context. It is complete enough for an agent to understand this is a multi-action management tool for a special calendar event type, though it could have explicitly routed to regular-calendar or out-of-office siblings for contrast.
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 parameters are already thoroughly documented with formats, defaults, and action-specific requirements. The description adds a conceptual layer by explaining the auto-decline and chat-status behavior that maps to auto_decline_mode and chat_status, but it does not need to restate the schema details. Baseline 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 names the specific resource (Focus Time events on Google Calendar) and explains their distinguishing behavior: auto-declining invitations and defaulting chat status to Do Not Disturb. It is clear what the tool operates on, though 'Manages' does not enumerate the create/list/update/delete actions covered by the action parameter.
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 establishes that this is for protecting uninterrupted work time and that these events behave differently from normal events, which implies when to use it. It does not explicitly name alternatives like manage_event or manage_out_of_office, nor does it state when not to use this tool.
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 adds a meaningful behavioral note beyond annotations: Slides comments are element-scoped via the Drive API and cannot be anchored to arbitrary text. This warns the agent about a real API limitation that annotations do not convey. The stated create/reply/resolve mutations are consistent with readOnlyHint=false and destructiveHint=false.
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, scannable, and front-loaded with the resource and action list. The API limitation note is placed where relevant, and no sentence is wasted.
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?
For a moderate-complexity management tool with an output schema and five parameters, the description covers the action semantics and the key API anchoring limitation. It could be more complete by pointing to list_presentation_comments for obtaining comment_id, but the essential call behavior is adequately specified.
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 0%, so the description must compensate. It does clarify action-conditional parameter requirements: create needs comment_content; reply needs comment_id and comment_content; resolve needs comment_id. However, it does not explain user_google_email, presentation_id, or the null defaults, leaving some parameters dependent on obvious naming.
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 names the resource (comments on a Google Presentation) and enumerates the three concrete actions: create, reply, and resolve. This distinguishes it from list-only or other document comment tools, though it does not explicitly reference sibling tool names.
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 action list gives implied usage context by stating which parameters each action requires. However, it does not explicitly say when to prefer this tool over list_presentation_comments or other manage_comment siblings, nor does it provide exclusions or fallback 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?
The annotations already declare readOnlyHint=false and destructiveHint=true, so the description need not restate that this is a mutating tool. It does add the specific actions (create, update, delete, move), but it does not disclose side effects, permission requirements, or reversibility beyond what annotations provide.
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 efficient sentence with a front-loaded verb and a concise action list. There is no wasted wording or redundant elaboration.
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 action list plus the richly documented 100%-covered input schema and existing output schema make the definition largely sufficient for correct invocation. It could be slightly more complete with explicit alternatives, but that gap is minor given the schema and annotations.
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 each parameter has a detailed description including which actions use it. The tool description itself adds no parameter-level meaning, so the baseline of 3 applies.
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 clear verb and resource: 'Manage tasks: create, update, delete, or move tasks within task lists.' It explicitly enumerates the supported operations and distinguishes this tool from sibling read-only tools like list_tasks/get_task and from task-list management via 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for task CRUD and moving operations, but it does not explicitly state when to use this tool versus alternatives such as list_tasks or get_task. There are no exclusions or routing guidance like 'for reads, use list_tasks instead.'
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?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the description does not need to restate that this tool mutates the document. It adds useful behavioral context by noting that heading, list, and paragraph changes can be combined in a single call. It does not disclose possible side effects like replacing existing list or paragraph structure, but the annotation coverage keeps this acceptable.
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 front-loaded: the first sentence states the core action and target, and the second sentence expands the capability set without repetition. The closing note that all operations can be applied in a single call is valuable and earns its place.
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?
For a complex 30-parameter write tool, the description, exhaustive schema, and existing output schema together are complete enough for an agent to select and invoke it correctly. It covers the operation, scope, formatting families, and single-call batching behavior. It could hint more strongly at using inspect_doc_structure for indices, but the schema already documents that for start_index.
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 documents all 30 parameters at 100% coverage, so the baseline is 3. The description adds category-level meaning (named heading styles, list nesting, alignment/spacing/indentation) but does not need to detail individual parameters because the schema already does that thoroughly.
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 names the exact verb ('Apply'), the resource ('paragraph-level formatting, heading styles, and/or list formatting'), and the scope ('to a range in a Google Doc'). This is specific enough to distinguish it from text-editing tools like modify_doc_text, insert_doc_elements, or generic batch_update_doc.
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 gives clear context by enumerating the formatting families it handles, so a capable agent can infer when to use it. However, it never explicitly contrasts this tool with siblings such as modify_doc_text, insert_doc_elements, or batch_update_doc, and it provides no 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?
Annotations already mark readOnlyHint=false and destructiveHint=false, so the mutation behavior is established. The description adds valuable behavioral context: it creates and populates a table in one operation, requires an index from inspect_doc_structure, enforces a 2D string-only format, and recommends debug_table_structure for verification. This goes beyond the annotations without contradicting them.
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 well-organized into sections and clearly front-loads the critical inspect_doc_structure call, but it is repetitive: the same index requirement is emphasized in the workflow, the critical requirements, and the schema parameter description. The all-caps warnings add urgency but also length without adding much 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?
For a tool with 7 parameters and an output schema, the description covers the essential invocation context: the mandatory prior call, how to derive the index, the exact table_data structure, and a post-verification step. It does not need to explain return values because an output schema exists, and the remaining schema fields like tab_id, header_rows, and bold_headers are already described in the input 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 schema already documents every parameter. The description adds meaningful semantics beyond the schema by showing the exact 2D array format with a header row example, requiring equal-length rows, and explicitly stating that empty strings should be used instead of None. This compensates for any ambiguity in the bare schema types.
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 opening line states a specific verb and resource: 'Creates a table and populates it with data in one reliable operation.' This is clear and distinct from the generic tool name, though it does not explicitly contrast with sibling tools like insert_doc_elements or create_sheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit mandatory workflow: call inspect_doc_structure first, use the returned total_length as the index, format data as a 2D list, and verify with debug_table_structure. It clearly states when to invoke this tool and the required precondition, though it does not discuss when not to use it or name an alternative.
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?
Annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) are consistent with the description, so no contradiction. The description adds genuine value beyond annotations: it discloses the side effect of writing to local disk and the mode-dependent return semantics (local path in stdio vs temporary URL with a 1-hour expiry in HTTP), which the annotations do not convey.
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 sentences carry all essential information with no filler. The core function is front-loaded in the first sentence, and the mode-specific details occupy the second. Every clause earns its place.
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 output schema exists to cover return values, and annotations cover the safety profile, lowering the burden on the description. The mode-specific behavior disclosure is a meaningful addition. Remaining gaps are the undocumented required user_google_email parameter and lack of error-behavior guidance (e.g., out-of-range attachment_index or messages with no attachments), but these are minor given the structured coverage.
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 67%, and the two documented parameters (message_id with a concrete example, attachment_index with default semantics) are well described. However, the required parameter user_google_email has zero documentation in both the schema and the description, and the description does nothing to compensate for this gap. With one required param unexplained, the agent cannot confidently construct valid calls.
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 first sentence states a specific verb ('Downloads'), resource ('attachment from a Google Chat message'), and outcome ('saves it to local disk'). It clearly distinguishes this from sibling tools like get_gmail_attachment_content (Gmail domain) and get_drive_file_download_url (URL only, not a download) by explicitly scoping to Google Chat.
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 operational context by explaining stdio vs HTTP mode return behavior, which helps the agent know what to do with the result. However, it never explicitly states when to use this tool versus similar alternatives such as get_gmail_attachment_content or get_drive_file_download_url; the routing is left to inference from the Chat domain in the name and description.
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?
Annotations already indicate destructiveHint=true and idempotentHint=false, so the safety burden is partially carried there. The description adds useful context that replacement happens 'throughout' the document and frames it as the 'safest way' to avoid index errors. It does not contradict the annotations, and no annotation contradiction is present.
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 core behavior and then provides a clear, scannable bullet list of use cases. It is slightly repetitive with 'safest way' and 'without risk of index errors,' but overall each section earns its place and the structure supports quick understanding.
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 and parameter coverage is complete, the description provides enough context for an agent to select and invoke the tool correctly. It covers scope, use cases, and a relevant alternative workflow. It could be more complete by explicitly noting that all occurrences are replaced or by naming index-based sibling tools, but these are gaps rather than blockers.
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 input schema already documents all six parameters. The description adds context around placeholder replacement and content updating, which helps illustrate find_text and replace_text usage, but does not substantially deepen the meaning of individual parameters 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 opens with a specific verb and resource: 'Finds and replaces text throughout a Google Doc.' It also adds a distinctive behavioral claim, 'No index calculation required,' which differentiates it from index-based document editing tools. The use-case bullets reinforce what the tool is for.
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 gives explicit when-to-use scenarios: replacing placeholders, updating words or phrases, and making targeted changes without index errors. It also names an alternative workflow using batch_update_doc for building documents from scratch. However, it does not explicitly contrast itself with sibling tools like modify_doc_text when index-based edits are needed.
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?
Annotations already declare the tool read-only and non-destructive, and the description adds useful behavioral detail by explaining the two retrieval paths: Docs API for native Google Docs and Drive API download with text extraction for Office files. This clarifies what the agent should expect for .docx and similar files.
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, front-loaded with the core purpose, and uses a short bulleted breakdown for the two supported file types. Every sentence contributes useful information with no 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?
Combined with full parameter descriptions, an output schema, and read-only annotations, the description gives an agent enough to invoke the tool correctly. It does not clarify sibling overlap or limitations beyond 'extracts text', but those are secondary for a read-only 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%, so the baseline is 3. The description adds important meaning by clarifying that document_id can identify either a native Google Doc or a Drive file such as .docx, which goes beyond the schema's parameter description.
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 uses a specific verb ('Retrieves') and a clear resource ('content of a Google Doc or a Drive file'), so the tool's purpose is immediately understandable. It does not explicitly differentiate itself from overlapping siblings like get_drive_file_content or get_doc_as_markdown, which keeps it from a 5.
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 by listing supported file types, but it gives no explicit when-to-use or when-not-to-use guidance and names no alternatives. An agent is left to infer that this is the right tool for Google Docs and Drive office files.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds no extra behavioral context beyond the read-only nature already implied by 'Gets' and the annotations, such as whether an existing link is returned or whether additional sharing state is involved.
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, front-loaded sentence states the exact operation and object with no filler. Every word earns its place, and it is appropriately short for a simple read tool.
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 low complexity, two fully documented parameters, rich annotations, and an available output schema, nothing essential is missing. The description adequately orients an agent toward correct invocation without needing to restate structured information.
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 parameters are already fully documented. The description adds no additional meaning beyond what file_id and user_google_email already convey, so it meets but does not exceed the 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 uses a specific verb ('Gets') with a specific resource ('the shareable link') and explicitly scopes it to 'a Google Drive file or folder.' This distinguishes it from sibling tools like get_drive_file_download_url and get_drive_file_content without needing to open schemas.
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 intended use is implied: use when you need the shareable link for a Drive item. However, there is no explicit guidance on when to choose this over alternatives such as get_drive_file_download_url or get_drive_file_permissions, and no mention of prerequisites or 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?
The description adds meaningful behavioral context beyond the annotations: it mentions the local disk side effect, the difference between stdio and HTTP return modes, the one-hour URL validity, and the potential metadata re-fetch. This complements the annotations rather than contradicting them.
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 and front-loaded. The first sentence states the core action, and the following sentences add only necessary mode-specific and behavioral details. Every sentence earns its place with no redundant 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 the input schema is fully documented and an output schema exists, the description covers all necessary behavioral aspects: side effects, mode-dependent returns, and metadata re-fetching. The agent has enough information to invoke the tool correctly and interpret the expected outcome.
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 input schema already fully documents message_id, attachment_id, user_google_email, and return_base64. The description does not add parameter-level detail, but the schema carries that burden, so a 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 uses a specific verb and resource: 'Downloads an email attachment and saves it to local disk.' It clearly identifies what the tool does and distinguishes it from sibling tools that retrieve message content or thread content, since it focuses specifically on attachment download.
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 explains mode-specific behavior (stdio vs HTTP) but provides no explicit guidance on when to choose this tool over alternatives such as get_gmail_message_content, get_gmail_messages_content_batch, or download_chat_attachment. There are no exclusions, prerequisites, or sibling comparisons.
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?
The annotations already supply the safety profile (readOnlyHint, idempotentHint, non-destructive). The description adds that the result is a URL and that it targets a single slide, but it does not disclose authentication prerequisites, URL lifetime, or other behavioral details. 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?
A single sentence with no filler. The action and target are front-loaded, and every word contributes meaning.
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, idempotent thumbnail-URL tool with full parameter documentation, strong annotations, and an output schema, the description is sufficient. Nothing critical for invoking the tool correctly is missing.
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 each parameter is already documented with a useful description. The tool description only reinforces that page_object_id refers to a slide and does not add meaningful parameter-level 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 uses a specific verb ('Generate') and a precise resource ('thumbnail URL for a specific page (slide) in a presentation'). It clearly distinguishes this tool from siblings like get_page, which would return slide content rather than a thumbnail URL.
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 intended purpose is clear from the description, but it does not explicitly state when to use this tool over alternatives such as get_page, nor does it mention prerequisites or exclusions. Usage context is implied by the resource targeted, not explicitly spelled out.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the operation's safety profile. The description adds minimal contextual value beyond 'including its sheets'; it does not disclose auth requirements, error conditions, or other behavioral traits, though none are strongly needed given the simple 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single direct sentence contains all essential information with no filler. The key scoping detail ('specific spreadsheet') is front-loaded, and the additional 'including its sheets' detail is valuable without adding clutter.
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 read-only metadata lookup, the description combined with complete parameter schemas, strong annotations, and an output schema provides enough context for an agent to select and invoke the tool correctly. No critical missing information is 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 description coverage is 100%, so both parameters are already self-documented. The description provides no additional semantic detail about parameters, which is acceptable because the schema fully carries the load.
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 a specific verb ('Gets information') and a specific resource ('a specific spreadsheet'), and notes the included 'sheets' detail. This distinguishes it from sibling tools like list_spreadsheets, which would return a collection rather than a single spreadsheet's metadata.
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 information about one identified spreadsheet. However, it does not explicitly state when not to use it or mention alternatives such as list_spreadsheets or read_sheet_values, so the usage guidance is only implicit.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the scope ('all deployments for a script project') and does not disclose additional behavioral details such as pagination, ordering, or authentication requirements. This adds some value but is minimal beyond 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 a single, focused sentence with no filler. It front-loads the action ('Lists') and clearly identifies the resource and scope, making it easy for an 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?
For a simple read-only listing tool, the description combined with the rich annotations and output schema provides sufficient context. The two required parameters are covered by the schema, and the annotations handle safety expectations. Nothing essential is missing for an agent to invoke 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 description coverage is 100%, so both required parameters are already documented in the input schema. The description adds no extra meaning about parameter formats, defaults, or relationships. Baseline 3 is appropriate since the schema carries the full parameter documentation burden.
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 a specific verb ('Lists'), a specific resource ('deployments'), and a clear scope ('for a script project'). This distinguishes it from related sibling tools like manage_deployment and list_versions without ambiguity.
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 makes it clear this is a listing operation, which implies when to use it, but it does not explicitly state when not to use it or mention alternatives such as manage_deployment. There is no exclusion or routing guidance beyond the verb 'Lists'.
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?
Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the risk profile is covered without description support. The description adds that the tool mutates link-sharing and file-level settings, but it does not disclose consequences such as revoking anonymous access when link sharing is turned off or changes taking effect immediately. This is adequate but not rich 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 short, front-loaded sentences, each earning its place: primary purpose, high-level positioning, when-to-use, and when-not-to with routing. There is no repetition or filler, and the structure naturally separates what the tool does from how to choose it.
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?
An output schema exists and the annotations are rich, so the description need not explain return values or safety profiles. The main gap is the unresolved user_google_email requirement, which directly threatens correct invocation given the tool's stated link-sharing purpose; the routing to sibling tools absent from the list is a secondary but real gap. Overall adequate for a well-schema'd tool, but not fully 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% and each parameter (link_sharing, writers_can_share, copy_requires_writer_permission) has a detailed description, so the schema carries the heavy lifting. The description adds high-level framing that most parameters are optional toggles, but it leaves the required user_google_email unexplained — its role conflicts with the link-sharing positioning, and neither the description nor the schema reconciles this.
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?
"Sets file-level sharing settings and controls link sharing for a Google Drive file or folder" provides a specific verb, resource, and scope, making the tool's function immediately clear. The second paragraph reinforces purpose by positioning it as a high-level tool for common permission changes and explicitly excluding granular user/group permission management, distinguishing it from read-oriented siblings like get_drive_file_permissions.
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 gives explicit when-to-use guidance ("toggle 'anyone with the link' access or configure file-level sharing behavior") and an explicit exclusion ("For managing individual user/group permissions, use share_drive_file or update_drive_permission instead"). However, those named alternatives are absent from the sibling-tools list (which instead contains manage_drive_access), and the required user_google_email parameter blurs the stated boundary between this tool and individual-user permission 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?
Annotations already convey the key behavioral traits: non-read-only, non-idempotent, non-destructive, open-world. The description confirms the mutating creation behavior and adds shared-drive support as extra context. It does not detail auth requirements or side effects, but the annotation coverage lowers 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?
The description is a single, front-loaded sentence that states the core action first and adds the shared-drive qualifier without redundancy. It contains no filler and does not repeat schema or annotation 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?
For a straightforward create operation, the description, schema, and annotations together give an agent enough to invoke the tool correctly: required parameters are documented, safety traits are annotated, and an output schema exists. Minor details like permission prerequisites are unstated but are not essential for basic 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 the schema already documents all parameters. The description's shared-drive mention aligns with and echoes the existing parent_folder_id schema note rather than adding materially new 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 states a specific verb and resource: 'Creates a new folder in Google Drive.' It clearly distinguishes from siblings like create_drive_file by limiting the action to folders, and it adds the meaningful shared-drive capability without ambiguity.
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 gives clear context for when to use the tool: creating folders in Google Drive, including within shared drives. It does not explicitly name alternatives or exclusions, but the resource type is unambiguous enough that an agent can route to this tool for folder creation versus file creation.
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?
Annotations already establish this is a mutating (readOnlyHint=false), non-idempotent operation. The description adds genuinely useful behavioral context beyond annotations: versions are immutable snapshots, and 'Once created, versions cannot be modified' warns the agent of a permanent consequence. This is consistent with idempotentHint=false and destructiveHint=false, with no contradiction.
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 tight sentences with zero waste: the core action is front-loaded, the second sentence explains what a version is, and the third states the critical constraint. Every sentence earns its place and no information is repeated from the schema or annotations.
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 an output schema exists (so return values need no explanation) and annotations cover the safety profile, the description adequately conveys the semantics and the immutable nature of the created artifact. A minor gap is the absence of guidance on prerequisites or sequencing relative to update_script_content, but nothing essential blocks correct 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 all three parameters (script_id, description, user_google_email) are already documented structurally. The description adds minimal param-specific meaning beyond reinforcing that the snapshot captures 'current script code' for the given script project. Baseline 3 is appropriate; 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 opens with a specific verb-resource pair ('Creates a new immutable version of a script project') and adds the key attribute 'immutable'. This clearly distinguishes it from siblings like list_versions, get_version, create_script_project, and update_script_content, so an agent can tell them apart without inspecting schemas.
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 use case — 'Versions capture a snapshot of the current script code' suggests you call this when you want to freeze the current code state. However, it never explicitly names alternatives or states when not to use it (e.g., when you need to modify code first via update_script_content, or when you simply want to view versions via list_versions).
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context about the API limitation and the code-generation nature of the tool, but does not go beyond that into further behavioral details such as output format or 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?
The description is brief, front-loaded with the core purpose, and every sentence adds value. The constraint explanation is essential context and is presented in two compact sentences 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?
Given the tool's moderate complexity, the rich input schema, and the presence of an output schema, the description is complete enough. It explains the key contextual constraint (API cannot directly create triggers) and the tool's role without needing to restate structured details.
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 input schema already documents all parameters thoroughly. The description does not add parameter-level meaning, meeting the baseline for a fully documented 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 a specific verb ('Generates') and identifies the exact resource ('Apps Script code for creating triggers'). It clearly distinguishes what the tool does from siblings by focusing on code generation rather than direct trigger creation or script 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?
The description explains when this tool is needed: because the Apps Script API cannot create triggers directly and they must be created from within Apps Script itself. This provides clear context for when to use the tool, though it does not explicitly name alternative tools or 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?
Annotations already establish the safety profile (readOnlyHint, idempotentHint, non-destructive, openWorld), so the bar for the description is lower. The description adds meaningful behavioral context beyond annotations: the tool returns ALL messages in the thread, and the include_analysis flag flips the return shape from a formatted string to a structured dict containing last sender, ball-in-court verdict, per-sender counts, and participants. This explains behavior the annotations cannot convey and does not contradict them.
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 with zero waste: the first states the core function, the second explains the optional value-add and its benefit. The efficiency framing ('without re-parsing the formatted string or making a second tool call') earns its place by clarifying why the optional feature exists. Front-loaded, appropriately sized, no 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?
With an output schema present, return-value documentation is handled elsewhere; annotations cover the read-only/idempotent profile; and the schema covers all parameters at 100%. The description is complete for the core task. The only meaningful gap is explicit routing to sibling alternatives (batch vs. single vs. message-level), which would round out the contextual picture but is not critical given the clear thread-scoped purpose.
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 four parameters thoroughly, including defaults and enum semantics for body_format and include_analysis. Per the baseline rule, the description needn't repeat this. It adds marginal value by explaining the intent behind include_analysis ('who owes whom a response') but provides no additional meaning for thread_id, body_format, or user_google_email beyond what the schema already states.
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 opens with a specific verb+resource: 'Retrieves the complete content of a Gmail conversation thread, including all messages.' This clearly distinguishes it from siblings like get_gmail_message_content (single message) and search_gmail_messages (search), and the second sentence's ownership-analysis feature further differentiates it from get_gmail_threads_content_batch.
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 a use case — 'so a caller can determine who sent the last message and who owes whom a response... without making a second tool call' — which tells the agent when the optional analysis is valuable. However, it never explicitly addresses when NOT to use this tool or names alternatives (e.g., use get_gmail_threads_content_batch for multiple threads, get_gmail_message_content for one message). The guidance is implied, not stated.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the read-only nature is covered elsewhere. The description adds the optional max_comments limiting behavior, but does not mention pagination, authentication requirements, or completeness caveats. This is adequate but not especially 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?
The description is a single, front-loaded sentence with no filler. The core action and resource are stated first, and the optional parameter is cleanly parenthesized, making it highly scannable.
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?
For a simple read-only listing tool with an output schema, the description covers the core action, target resource, and optional limit. A note about the required user_google_email or how it connects to Google authentication would make it fully complete, but that is inferable from the parameter name and sibling tools like start_google_auth.
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 schema has 0% description coverage, so the description needs to compensate. It explains max_comments as a result limiter and implies document_id identifies a Google Document, but it does not explain the required user_google_email parameter or its role, leaving a meaningful gap for one of the two required 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 ('comments from a Google Document'), making it clear what the tool does. It also distinguishes itself from comment-related management tools and from spreadsheet/presentation comment listing tools via the explicit 'Google Document' scoping.
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 context: use this tool to retrieve comments from a Google Document, not from spreadsheets or presentations, and not to manage comments. However, it does not explicitly name alternatives like manage_document_comment or state when not to use this tool, so it falls just short of full 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds valuable context that versions are immutable snapshots created by deployments or explicit creation, which clarifies the data scope and reinforces the non-mutating 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?
Two short sentences with the core action front-loaded and the supporting snapshot context in a compact second sentence. No filler or 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?
For a simple two-parameter read-only listing tool with full schema coverage and an output schema, the description covers what the tool does and the domain context. It does not mention pagination or ordering, but that is reasonably left to the 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 the two parameters (script_id, user_google_email) are already documented. The description adds no further parameter-level detail, so it meets the baseline for schema-covered 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 opens with a specific verb+resource: 'Lists all versions of a script project.' It clearly distinguishes from sibling tools like get_version (single version) and create_version (write operation) by emphasizing 'all versions' and the snapshot nature.
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?
No alternatives are named or exclusions given, but the immutability and creation context implies this is for enumerating historical script snapshots. It does not explicitly say when to prefer list_versions over get_version or list_deployments, leaving usage mostly implicit.
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?
Annotations already communicate that the tool is destructive, non-read-only, and non-idempotent, so the description need not repeat that. It does not add extra behavioral context beyond the listed actions, such as the cascading delete_contacts side effect, which is left to the parameter 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 with no filler. The core operations are front-loaded, and the consolidation rationale is stated in one short follow-up sentence.
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 full schema coverage and an output schema, an agent has enough structured detail to invoke the tool correctly. It could be improved by explicitly routing users to read-only group tools or highlighting the delete_contacts cascade, but the core consolidation intent is clear.
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 applies. The description's action list maps directly onto the action parameter values, but it does not add dependency or relationship details 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 states a clear set of actions—create, update, delete, or modify members—tied to a specific resource: contact groups. It also distinguishes itself by explicitly noting it is a consolidated replacement for several older 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 clearly establishes this as the tool to use for contact group mutations, replacing four dedicated tools. However, it does not explicitly state when to prefer read-only siblings like list_contact_groups or get_contact_group.
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?
The description goes well beyond the annotations by revealing the batchUpdate sequence (copyPaste then deleteDimension), the lack of rollback on partial failure, and the risk of duplication if only the delete fails. It also discloses that formulas, data types, and formatting are preserved, and clarifies 1-based row indexing. This is rich, non-obvious behavioral detail that materially affects invocation and outcome expectations.
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 front-loaded with the primary action, followed by implementation detail, a critical failure caveat, and a preservation note. Every sentence conveys essential operational or behavioral information without fluff. The structure allows an agent to quickly grasp what the tool does and what risks to anticipate.
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?
For a mutation tool with destructive annotations and an output schema, the description covers the critical behavioral aspects: execution mechanism, failure semantics, preservation guarantees, and row indexing. It does not explicitly mention prerequisites such as the destination sheet needing to exist or constraints like source and destination differing, but these are less critical given the schema and output schema already provide structure. Overall, enough context is present for correct 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 the schema already documents all six parameters including the 1-based and inclusive nature of start_row and end_row. The description adds minimal parameter-level value beyond reaffirming 1-based row numbers and noting rows are moved within the same spreadsheet. This matches the baseline of 3 for full schema coverage.
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 action: 'Moves rows from one sheet to another within the same spreadsheet.' This is a specific verb and resource, distinct from typical read/write tools. However, it does not explicitly name a sibling tool for differentiation, instead relying on the phrase 'unlike a values.get/append round-trip' to contrast with an approach rather than a specific named alternative.
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?
Usage context is implied rather than explicit. The description explains that formatting and formulas are preserved 'unlike a values.get/append round-trip,' which hints at when this tool is preferable, but it does not state clear when-to-use vs. when-not-to-use conditions or name alternatives. An agent must infer that this tool is for full-fidelity moves within the same spreadsheet.
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?
Annotations already establish read-only, idempotent, non-destructive behavior, so the description does not need to repeat that. It adds useful context beyond annotations by marking the tool as temporary and diagnostic, clarifying that it inspects runtime/source state rather than user data.
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 tightly written sentences with no filler. The main action and diagnostic purpose are front-loaded, and the temporary nature is stated concisely in the second sentence.
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?
For a simple one-parameter tool with a rich output schema and strong annotations, the description covers what the tool does and when to use it. The only notable gap is the unexplained parameter semantics, which is partially mitigated by the clear parameter name.
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 needed to explain the required `user_google_email` parameter but does not. The parameter name is somewhat self-explanatory, but the description does not clarify whose email is expected or how it is used for diagnosis.
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 a specific verb and resource: 'Return runtime/source information' and 'verify which code checkout the running MCP server has loaded.' It clearly distinguishes itself as a temporary diagnostic tool among the many operational Google Workspace 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 explicitly identifies the use case: 'diagnosing stale MCP server instances' and verifies which code checkout is loaded. It gives clear context for when to use the tool, though it does not name alternatives or exclusions, which are largely unnecessary given its unique diagnostic role.
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?
Annotations already mark the tool as read-only, idempotent, and non-destructive; the description adds valuable behavioral detail by specifying exactly what the output contains and how to interpret fields like dimensions, position, current_content, and insertion_index. It also makes clear the tool inspects rather than mutates, with no contradiction to annotations.
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 long but well-structured with bolded trigger conditions, output explanations, and workflow steps that are easy to scan. Each section conveys actionable guidance, though some repetition of the tool's core purpose could be trimmed.
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 when to use the tool, how to read its output, and how it fits into a workflow, while the output schema handles the return structure. One minor gap: it references 'populate_existing_table' as a scenario, but that tool does not appear in the sibling tool list, creating slight routing 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?
The input schema already documents all three parameters with helpful descriptions and a default for table_index. The description does not add parameter-specific guidance beyond what the schema provides, so the baseline score of 3 is appropriate given 100% schema coverage.
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 debugs table structure and enumerates what it reveals: dimensions, cell positions, current content, insertion indices, and boundaries. It is unambiguous about the resource and purpose, though it does not explicitly contrast with sibling inspection tools like inspect_doc_structure or create_table_with_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?
The description provides an explicit 'USE THIS IMMEDIATELY WHEN' list and a workflow integration section covering after creation, before population, and after failures. It lacks an explicit when-not-to-use section or named alternative tools, so it stops short of 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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context about the different retrieval modes and optional keyword search, though it does not discuss pagination or default time-range behavior—those are covered by the parameter 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 three concise, front-loaded sentences with no filler. The primary verb and resource appear first, and the alternative retrieval modes are presented in a compact, easily parseable way.
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 retrieval tool with a complete input schema, an output schema, and readOnlyHint/idempotentHint annotations, the description plus structured metadata is sufficient for an agent to select and call the tool correctly. Nothing essential is missing from the description itself.
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 the schema itself already explains event_id precedence, time_min/time_max formats, query semantics, detailed output, calendar_id, and max_results. The description only summarizes a few parameter behaviors without adding new meaning, so it stays at the high-coverage 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 opens with a specific verb and resource: 'Retrieves events from a specified Google Calendar.' It then distinguishes three retrieval modes—by event ID, by time range, and by keyword—so an agent can immediately tell what this tool does and how it differs from event-management siblings.
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 patterns by describing event_id, time-range, and query modes, but it does not explicitly state when to avoid this tool or when to use a sibling like manage_event, query_freebusy, or list_calendars. The guidance is adequate but left mostly to inference.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds no behavioral nuance beyond labeling the operation as a 'get,' but it does not contradict the annotations either.
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 with no filler. The parenthetical '(slide)' adds useful disambiguation without unnecessary length.
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 low complexity, a complete output schema, fully documented parameters, and strong annotations, the description is sufficient for an agent to select and invoke the tool correctly. It does not need to explain return values because the output schema covers them.
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%, with all three parameters documented in the input schema. The description adds no parameter-specific details, so it does not compensate beyond the schema's baseline 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 a specific verb ('Get') and resource ('details about a specific page (slide) in a presentation'), making the tool's purpose immediately clear. It naturally distinguishes itself from presentation-level siblings like get_presentation and thumbnail-oriented get_page_thumbnail by specifying 'details' about a 'specific page.'
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 gives clear context: this tool is for retrieving a single page/slide's details rather than the whole presentation. It does not explicitly name alternatives or say when not to use it, so it lacks explicit exclusion guidance, but the scope is unambiguous enough for a simple getter.
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 meaningful behavior beyond annotations: Google Drive converts the file automatically and preserves slides, layouts, text, and images. It also notes that file_path is preferable for batch operations to reduce context loading. This is consistent with readOnlyHint=false and adds useful operational context, even if it does not mention duplicate creation or ownership 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?
The description is compact and well-structured: the first sentence states the core action, the second explains the conversion behavior, and the third gives a practical usage tip. Every sentence earns its place with no filler or 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?
The description is complete enough for an import tool: it explains supported formats, conversion behavior, preservation guarantees, and provides batch guidance. With an output schema present and detailed parameter descriptions, nothing critical is missing. A small gap is the lack of explicit mention that repeated imports may create duplicate presentations, though idempotentHint=false already signals this.
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 a baseline of 3 applies. The description adds value beyond the schema by recommending file_path for batch operations to avoid loading full file contents, which helps the agent select between parameters. It does not deeply explain all parameters, but the schema already handles that.
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 imports PPTX, PPT, and ODP files into Google Slides format with automatic conversion. It is specific about verb and resource, but does not explicitly distinguish itself from sibling tools like import_to_google_doc or import_to_google_sheets, though the Google Slides resource makes the intent fairly obvious.
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 gives a concrete usage guideline: for batch operations, prefer file_path so callers avoid loading full file contents into context. It provides clear context for when to use this parameter/approach, though it does not explicitly state alternatives or exclusions relative to other import/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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'labels' terminology and user scoping, but does not describe pagination or response behavior beyond the schema's own field descriptions.
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 efficient sentence that conveys the action, resource, and scope without wasted words. Every element 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, read-only list operation, the description plus rich annotations and fully documented schema provide everything an agent needs to select and invoke the tool correctly. An output schema is present, so return-value details are covered elsewhere.
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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description does not add parameter-level meaning beyond the schema, so the 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 states a specific verb ('List') and resource ('contact groups'), with a clarifying parenthetical 'labels' and a clear user scope ('for the user'). It is immediately distinguishable from siblings like get_contact_group 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: to enumerate a user's contact groups. It does not explicitly name alternatives or exclusion conditions, but the list-vs-get/manage distinction among sibling tools makes the usage context reasonably 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful scope information ('all structured tables') and return contents, but does not disclose potential pagination, rate limits, or authorization nuances. No contradiction with 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?
Two concise sentences with zero waste. The primary behavior and return contents are front-loaded, followed immediately by the practical purpose. 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?
Given the low complexity, two required parameters, full schema coverage, rich annotations, and an output schema, this description is complete. An agent can correctly invoke it and understand why the result matters for append_table_rows.
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 both parameters are described clearly ('The ID of the spreadsheet', 'The user's Google email address'). The description adds no additional parameter-level meaning, which is acceptable since the schema already carries the full burden.
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?
States a specific verb and resource: 'Lists all structured tables in a spreadsheet' with the exact outputs (IDs, names, ranges, column details). This clearly distinguishes it from siblings like list_spreadsheets, read_sheet_values, and get_spreadsheet_info.
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?
Gives explicit context: 'Use this to find table IDs for append_table_rows.' This tells the agent when to call it. It does not explicitly mention when not to use it or name alternative tools for reading sheet values, so it stops short of full 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?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful scoping context ('organization-wide' vs 'personal contacts') but does not disclose additional behavioral details like authentication requirements, pagination limits, or result ordering. It does not contradict the 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 a single sentence that states the operation, the resource, and a key differentiator. Every word contributes value without 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 straightforward read-only directory search, the description, combined with the fully documented schema and output schema, provides enough context for correct invocation. The 'not personal contacts' clarification prevents a common misuse and covers the main ambiguity among sibling tools.
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 all three parameters (query, page_size, user_google_email) are already documented. The description adds no parameter-level meaning beyond the schema, so the 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 uses a specific verb ('Search') with a clear resource ('Google Workspace domain directory') and explicitly contrasts it with personal contacts. This lets an agent distinguish it from sibling tools like search_contacts and list_contacts without inspecting schemas.
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 phrase 'organization-wide people lookup, not personal contacts' conveys clear context and an explicit exclusion. It doesn't name the alternative tool for personal contact search, but the boundary is clear enough for an agent to decide when to use this tool.
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?
Annotations already mark this tool as destructive and non-read-only; the description adds useful context by specifying that deleting form items, updating metadata, and changing settings are all possible. It does not contradict the annotations and gives the agent a clearer picture of 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?
The description is two sentences, front-loaded with the core purpose, and every sentence adds value. The supported-operation summary is compact and avoids redundant detail already present in the schema.
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?
For a mutation tool with destructive annotations and a 100%-covered schema, the description is largely complete. It could mention execution semantics such as request ordering, atomicity, or auth prerequisites, but the existing annotations and schema cover the main safety and parameter needs.
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 input schema already documents form_id, user_google_email, and the supported request types inside the requests parameter. The description summarizes the same operations but does not add meaning 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 states a specific verb and resource: 'Apply batch updates to a Google Form.' It enumerates the supported operations and adds 'primary method for modifying form content after creation,' which clearly separates it from create_form, get_form, and set_publish_settings among the siblings.
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 context: use this tool after form creation to modify content, metadata, or settings. It does not explicitly name alternatives or state when not to use it, but the 'primary method' phrasing and scope are enough to orient an 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?
Annotations establish that the tool mutates state but is not destructive. The description adds meaningful behavior beyond the schema: colors must be hex strings, number formats follow Sheets types, and an unspecified sheet means the first sheet is used. It does not mention whether existing formatting is overwritten, but the destructiveHint already frames the tool as non-destructive.
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 filler. It front-loads the core purpose, then provides concrete syntax guidance and a default-behavior note, all of which earn their place.
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, complete schema coverage, an output schema, and annotations, the description provides the essential operating rules without needing to restate every parameter. It could be slightly more explicit about overriding existing formatting, but nothing critical is missing for an agent to call this tool 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 description coverage is 100%, so the baseline is 3, but the description adds cross-cutting value by explaining the accepted format for colors, the Sheets-specific number format types, and the fallback behavior when range_name omits a sheet name. These details are not fully captured by the schema's per-parameter 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 opens with a clear active verb and resource: 'Applies formatting to a range,' then enumerates the kinds of formatting covered. This makes it distinct from value-editing spreadsheet siblings like modify_sheet_values or read_sheet_values.
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 usage context is implied by the formatting-specific vocabulary, but the description never explicitly says when to choose this tool over alternatives such as modify_sheet_values or manage_conditional_formatting. It adds a useful default-sheet note but no 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses the 20,000-character truncation, the disk-export/download-URL behavior for full=True, transport differences (HTTP vs stdio), and the stateless fallback. This is precisely the kind of behavioral context an agent needs to predict side effects and response shape.
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 purpose is front-loaded in a single sentence, and the follow-up paragraph is dense but essential, covering truncation, export behavior, and stateless deployments without filler. 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?
With a fully described schema, an output schema present, and annotations covering safety and idempotency, the description adds the remaining behavioral details needed for correct invocation. Nothing necessary is missing.
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 schema already documents each parameter. The description adds meaningful value by stating the default inline truncation limit and explaining why full=True matters—large messages never stream through the model context—which helps an agent reason about when to use it.
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 identifies the operation: retrieving the full content (subject, sender, recipients, body) of a specific Gmail message, with a concrete verb and resource. It does not explicitly contrast itself with sibling tools like the batch or thread variants, so it stops short of full sibling differentiation.
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 when full=True is needed (large messages, byte-exact fidelity) and the default truncation behavior. It does not, however, give explicit guidance on when to choose this tool over search_gmail_messages, get_gmail_messages_content_batch, or get_gmail_thread_content; usage context is implied rather than 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond annotations: the batch limit and the reason for it, which helps the agent understand the tool's operational constraints.
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 with no filler. The first sentence states the action and resource immediately; the second provides the key constraint and rationale. Every word earns its place.
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 output schema supplies return-shape details and the annotations cover safety, so the description only needs to convey scope and constraints, which it does. It could have explicitly pointed to get_gmail_message_content for single-message needs, but the clear naming and sibling list make that omission minor.
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%: all four parameters have meaningful descriptions and enums. The tool description only reinforces the 25-message limit already present in message_ids, adding no significant new parameter-level meaning, so the baseline score of 3 applies.
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 ('Retrieves'), names the resource ('content of multiple Gmail messages'), and clearly marks the batch scope, distinguishing it from the singular get_gmail_message_content sibling. 'Single batch request' reinforces the unique purpose.
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 states the appropriate context: fetching multiple messages in one batch, with a 25-message cap and the rationale (preventing SSL connection exhaustion). It does not explicitly name alternatives like the singular get_gmail_message_content, but the context is clear enough for an agent to decide.
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 behavioral details such as automatic conversion and preservation of formatting, which are not in the annotations. It also warns about file_path memory limitations and recommends avoiding very large files. However, it does not explicitly state that a new file is created (vs. updating an existing one), though that is implied. Overall, it adds meaningful context beyond the 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, consisting of three short sentences. It conveys all essential information without redundancy or unnecessary detail. The structure is efficient, with the main action stated first and operational hints provided afterward.
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 (7 parameters) and the presence of an output schema, the description is quite complete. It covers the core function, supported formats, and important caveats about file handling. It does not mention the return value, but that is presumably documented in the output schema. The description sufficiently contextualizes the tool for an agent to use it 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?
The schema already provides detailed descriptions for each parameter, including specific guidance for file_path and source_format. The tool description adds an extra hint about preferring file_path for batch operations, which is not in the schema. This supplementary guidance improves parameter understanding beyond the baseline, though the schema is already quite thorough.
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 ('imports a file') with specific formats (Markdown, DOCX, TXT, HTML, RTF, ODT) and the result (into Google Docs format with automatic conversion). It distinguishes the tool by its conversion capability, which is directly relevant to the tool's function.
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 some guidance on parameter choice ('For batch operations, prefer file_path') but does not explicitly compare this tool to alternatives like create_drive_file or import_to_google_slides. It lacks clear when-to-use vs when-not-to-use guidance beyond a single hint, so it is not fully explicit.
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?
Annotations already mark the operation as non-read-only, non-idempotent, and non-destructive. The description adds relevant behavioral context beyond that: automatic conversion to native Google Sheets, preservation of rows, columns, sheets, and values, and a note that file_path avoids loading file contents into context. There is no contradiction with 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 compact and front-loaded: the first sentence states the core operation, the second clarifies conversion behavior, and the third gives targeted file_path guidance. Every sentence earns its place and there is no redundant restatement of schema fields.
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 and fully documented input schema, the description covers the essential behavior and a key performance/context decision (file_path for large/batch imports). It does not explicitly contrast with create_spreadsheet or mention authentication prerequisites, but the missing guidance is minor and inferable from the sibling set.
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?
With 100% schema coverage, the baseline is 3, and the description adds extra decision value by advising file_path for disk files and for batch operations. It also explains what conversion preserves, which helps callers interpret the results associated with file_name and source_format.
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 and resource: 'Imports a spreadsheet (XLSX, XLS, ODS, CSV, TSV) into Google Sheets format with automatic conversion.' This clearly separates it from sibling importers like import_to_google_doc and import_to_google_slides by naming the target format and source types.
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 gives useful parameter-level guidance ('For batch operations, prefer file_path for files on disk so callers do not need to load full file contents into their context'), but it does not state when to use this tool versus alternatives such as create_spreadsheet or create_drive_file. Usage is implied rather than explicitly scoped.
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 adds meaningful behavioral context beyond the annotations: comments are document-level, and the Drive API cannot anchor comments to specific text, only the Google Docs UI can. This limitation is important and helps set expectations. The annotations already signal mutation (readOnlyHint false), so the description does not need to restate that.
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 and well structured: a one-line overview, then a bulleted action list, then a single note that prevents a common misuse. Every sentence contributes information, and the most important scoping/limitation information is front-loaded near its relevant 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?
For a composite mutation tool, the description covers the action-dependent parameter requirements and the key API limitation, while the output schema covers return values. It could be slightly more explicit about not using comment_id when creating and about using list_document_comments to fetch comment IDs, but overall it gives an agent enough to invoke the tool 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?
With 0% schema description coverage, the description carries the load by mapping each action to its required parameters: create needs comment_content, reply needs comment_id and comment_content, and resolve needs comment_id. This is essential because the schema only lists the parameters without relationships. It does not elaborate on user_google_email or document_id, but those are self-explanatory from their names and the required 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 opens with 'Manage comments on a Google Document' and then enumerates three specific operations (create, reply, resolve), so an agent knows exactly what the tool does. The resource scope (Google Document comments) distinguishes it from sibling tools managing spreadsheet or presentation comments.
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 action list makes the intended use fairly clear and each bullet states which parameters the action requires. However, it does not explicitly state when to prefer list_document_comments for reading comments or mention that comment_id should be obtained beforehand, so the guidance is implied rather than explicit.
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?
Annotations already mark this as destructive and non-read-only, and the description adds meaningful behavioral detail: removing INBOX achieves archiving, adding TRASH achieves deletion. These are side-effect semantics not visible in the schema and not covered by the annotations, so the description provides real additional value without contradicting the 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 three short sentences with no repetition or filler. The core purpose is front-loaded, and the two additional sentences each carry concrete, non-obvious usage 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?
With 100% schema coverage, annotations, and an output schema, the description covers the essential special-label behavior and destructive implications. It is slightly incomplete in not mentioning that multi-message operations could use batch_modify_gmail_message_labels, but this is a modest gap rather than a serious omission.
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 baseline is 3. The description goes beyond the schema by naming concrete label IDs (INBOX, TRASH) and mapping them to high-level intents, which helps an agent populate add_label_ids and remove_label_ids meaningfully.
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 specific verb and resource: 'Adds or removes labels from a Gmail message.' This clearly distinguishes the tool from label-management siblings like manage_gmail_label and gives concrete meaning to the operation. The archive/delete examples further clarify the purpose.
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 gives practical usage clues: 'To archive an email, remove the INBOX label' and 'To delete an email, add the TRASH label.' However, it never explicitly tells the agent when to choose this tool over the sibling batch_modify_gmail_message_labels or how it differs from manage_gmail_label. The usage guidance is useful but implied rather than explicit.
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 goes beyond the destructiveHint annotation by spelling out the actual structural modifications: deleting/inserting rows and columns, hiding/unhiding, and freezing. This makes the mutating nature concrete for the agent. It stops short of noting consequences like irreversible data loss from deletion, but the annotations already flag destructiveness.
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 states the tool's scope and then lists its operation groups in a compact, scannable list. There is no filler or redundant explanation.
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 large parameter surface (20 params), the description plus the fully documented schema and existing output schema provide enough for an agent to invoke the tool correctly. It could add a note about combining multiple operations in one call, but that is reasonably implied by the optional 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 description coverage is 100%, so the input schema already documents every parameter with types, defaults, and examples. The tool description only summarizes operation categories and does not add parameter-level semantics, which is acceptable given the schema's richness.
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 specifies the tool's domain: sheet-level dimension properties, and enumerates the concrete operations (resize, auto-resize, freeze, hide/unhide, insert/delete rows/columns). This distinguishes it from sibling sheet tools like modify_sheet_values or format_sheet_range, which handle content and formatting rather than dimensional structure.
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 context for when to use the tool: whenever an agent needs to alter row/column dimensions, visibility, or structure. It does not explicitly name alternatives or exclusion conditions, but the operation list is specific enough to route selection correctly among the large sibling set.
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?
Annotations already indicate a non-read-only, non-idempotent, non-destructive operation. The description adds useful behavioral context by specifying that rows are appended to the end of the table body and that the table range automatically extends. This clarifies the exact side effect without contradicting the 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 short, front-loaded with the core action, and every sentence contributes: one defines the operation and behavior, the other provides the essential prerequisite. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple append operation, the description is complete: it covers what the tool does, the side effect on the table range, and the required discovery step for table_id. The output schema handles return-value expectations, and annotations handle the safety profile, so no critical guidance is missing.
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 fully documents all four parameters. The description only reinforces that table_id comes from list_sheet_tables, which is already stated in the schema's table_id description, so it adds no significant new 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 states a specific verb and resource: 'Appends rows to a structured table in a Google Sheet.' It also explains the distinctive behavior—rows are added to the end of the table body and the range is automatically extended—which clearly separates it from plain spreadsheet writers like modify_sheet_values or table creation 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 gives a concrete prerequisite: 'Use list_sheet_tables first to find the table ID,' which tells the agent the required preceding step. It does not explicitly discuss when not to use this tool or name alternatives, so it stops short of full when/when-not 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?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavioral detail beyond them: per-format export/parsing strategies, PDF fallback behavior, base64/MIME for images, and a binary-note fallback for unknown file types. This is rich disclosure of how the tool behaves in various scenarios.
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 and well-structured: a single lead sentence followed by a scannable bullet list where each item covers a distinct file category. No sentence is wasted, and the most important usage information (retrieves content by ID, supports shared drives) 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?
The tool has an output schema, so return-value details are already structured. The description covers all likely input file types, fallback behaviors, and edge cases such as binary files, making it sufficient for an agent to understand what will happen for any file. Combined with the annotations and schema, the description is contextually 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?
Input schema coverage is 100% and both parameters already have reasonable descriptions. The tool description adds little beyond the schema: it mentions 'by ID' and the fact that shared drives are supported, but it does not deepen the meaning of user_google_email or provide guidance on acquiring a file_id. This matches the baseline of 3 for 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?
The description opens with a precise verb+resource statement: 'Retrieves the content of a specific Google Drive file by ID,' which clearly defines what the tool does. The bulletized format-specific breakdown further distinguishes it from related siblings like get_drive_file_download_url or get_doc_content by showing it returns extracted text/content rather than a URL or a Docs-specific artifact.
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 clearly implies when to use the tool: whenever you need the content of a Google Drive file, including shared drives. However, it never explicitly names alternatives such as get_drive_file_download_url or get_doc_content, nor does it state when to prefer one over the other; the guidance is inferred from the format-handling bullets rather than 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?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the description only needs to add value beyond that. It does so by explaining the return payload (IDs, thread IDs, web links) and pagination via page_token, which are useful behavioral details not carried by 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 sentences cover the core behavior, return values, and pagination with no filler or repetition. The most important information is front-loaded, and every sentence contributes to an agent's ability to select and invoke the tool.
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 search tool with a fully described schema and an output schema, the description is complete: it states what is searched, what is returned, and that pagination is supported. Parameter details and return structure are already covered by the schema and annotations, so nothing essential is missing.
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 schema already documents query, page_size, page_token, include_headers, and user_google_email. The description only restates pagination support and does not materially add 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 uses a specific verb ('Searches') and resource ('messages in a user's Gmail account') and clearly states what is returned: Message IDs, Thread IDs, and Gmail web links. This distinguishes it from content-retrieval siblings like get_gmail_message_content and get_gmail_thread_content, since the focus is on search results and identifiers, not message bodies.
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 makes the tool's context clear: use it to find Gmail messages by query and get identifiers and verification links, with pagination support. It does not explicitly name alternatives or state when not to use it, but the search-versus-content-retrieval distinction is strongly implied by the result contents.
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?
The description goes beyond annotations by revealing important internal details: the body starts at index 1, a new empty doc has total length 2 with a section break at index 0 and newline at index 1. This is exactly the kind of behavioral context that helps an agent understand side effects and subsequent index calculations. No contradiction with annotations.
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 mostly concise and front-loaded with the primary purpose. It includes useful operational details, though the inner-document index explanation could be tightened slightly. Overall, every sentence earns its place and no filler exists.
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 the tool has an output schema, fully described parameters, and annotations, the description provides complete context for correct invocation. It covers creation behavior, initial content limitations, and a clear follow-up workflow. Nothing critical is missing for an agent to use the tool effectively.
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 significant parameter-specific semantics beyond what the schema already documents. It does clarify that the content parameter is for initial plain text and that rich content should be built with batch_update_doc, but this is contextual rather than parameter-specific.
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 opens with a specific verb and resource: 'Creates a new Google Doc and optionally inserts initial content.' This clearly states the tool's function and differentiates it from siblings like import_to_google_doc and create_drive_file by explicitly focusing on creating a Google Doc from scratch.
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 workflow guidance: after creation, use batch_update_doc with insert_text operations and end_of_segment=true, then inspect_doc_structure before formatting. It does not explicitly compare create_doc with alternative creation tools like import_to_google_doc, but the post-creation workflow is strong enough to guide an agent on when and how to proceed.
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?
Annotations cover the read-only, idempotent, non-destructive profile. The description adds meaningful behavioral context about drive_id scoping, folder_id relativity, include_items_from_all_drives behavior, and the shared drive container mode. It does not contradict annotations; minor omission is listing depth (immediate vs recursive).
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 dense sentences with no filler. The main action is front-loaded, and the conditional branches are expressed compactly. Every sentence earns its place.
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 high parameter count and two distinct modes, the description covers the primary scenarios and parameter relationships. Minor gaps like pagination behavior and non-recursive listing are largely handled by the schema and output schema, making it fairly 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 covers all 13 parameters with 100% description coverage, so baseline is 3. The description adds cross-parameter semantics: it explains how drive_id, folder_id, resource_type, and include_items_from_all_drives interact based on whether drive_id is set, which is more than the sum of individual 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?
Description states a clear verb ('Lists') and distinguishes two modes: files/folders vs shared drive containers. It also explains drive scoping behavior, which differentiates it from siblings like search_drive_files.
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 conditional guidance: if drive_id is specified, list within that drive; if not, list My Drive and accessible shared drives; set resource_type to 'shared_drives' for containers. However, it does not explicitly contrast with search_drive_files or state when not to use this tool.
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?
Annotations already signal write behavior via readOnlyHint=false, and the description adds a meaningful operational caveat: the Drive API cannot anchor comments to arbitrary text and Sheets comments are cell-scoped. This goes beyond the annotations without contradicting them.
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 and front-loaded, with each bullet contributing either a clear action definition or a critical API limitation. The cell-scoping note is the only extra detail and it adds genuine 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?
For a multi-action mutation tool with no schema-level parameter descriptions, the definition covers the main invocation paths and required fields, and the output schema can handle return values. Minor gaps remain around exact action enum values and the meaning of user_google_email, but these do not block correct usage.
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?
With 0% schema description coverage, the description compensates by tying parameter requirements to specific actions, clarifying the roles of comment_content and comment_id. It does not explain user_google_email or spreadsheet_id, but those are largely inferable from their names and the tool's Google Workspace 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?
The description states a specific verb-resource pair, 'Manage comments on a Google Spreadsheet,' and breaks out concrete actions: create, reply, and resolve. This makes it clearly distinct from sibling tools like manage_document_comment and manage_presentation_comment.
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 action list gives clear context for when to use the tool and what each action requires, such as 'create: ... Requires comment_content' and 'reply: ... Requires comment_id and comment_content.' It does not explicitly name alternatives or exclusions, but the usage boundaries are unambiguous.
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?
Annotations already declare readOnlyHint=false and idempotentHint=false, and the description adds meaningful behavior beyond that: forwarding carries the original subject/body/attachments, quotes with a 'Forwarded message' header, and disables threading/reply/signature options. This prevents an agent from incorrectly assuming subject or signature behavior applies in forward mode. No contradiction with 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?
Two tight paragraphs: the first front-loads the core purpose and supported modes in a single sentence, and the second covers only the forwarding behavior that needs disambiguation. There is no filler and no repetition of schema content — every sentence earns its place.
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?
For an 18-parameter tool with an output schema and annotations, the description covers the core operation, all three modes, and the highest-misuse-risk behavior (forwarding) in detail. Remaining details like reply_all recipient derivation and inline attachment content_id mechanics are already fully documented in the schema, so the description doesn't need to restate them.
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 the baseline is 3, but the description adds cross-parameter semantics the per-parameter schema entries cannot: in forward mode, body is treated as an optional note, subject becomes optional/defaulted, and reply/threading/signature parameters are ignored. This reconciles interactions among forward_message_id, body, subject, thread_id, and include_signature.
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 opens with a specific verb+resource ('Sends an email using the user's Gmail account') and precisely scopes the tool: new emails, replies, forwards, optional attachments, and Send As aliases. The 'Gmail account' qualifier plus the send verb separates it from siblings like draft_gmail_message and the Chat-focused send_message, even without naming them.
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 clearly articulates the three usage modes (new, reply, forward) and gives explicit operational guidance for forwarding — pass forward_message_id, the original subject/body/attachments are carried over, body becomes a prepended note, subject is optional. It does not name alternative tools or state explicit when-not-to-use conditions, so it stops short of a 5.
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?
Beyond the minimal annotations, the description discloses that this is a legacy OAuth 2.0 tool, disabled when OAuth 2.1 is enabled, and that authentication is normally handled automatically by the system. It also explains the manual tool's role in re-authentication, proactive auth, and retry scenarios, which is rich 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?
The description is well-structured: a clear opening statement, a critical legacy note, a numbered list of use cases, and a closing recommendation. Every sentence carries distinct information without 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?
The description thoroughly covers purpose, usage conditions, alternatives, and legacy/automatic behavior, and the output schema can handle return-value documentation. However, it is not fully self-contained because it leaves parameter semantics unexplained, which is a meaningful gap for an agent deciding what to pass as service_name.
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 input schema has 0% parameter description coverage, and the description does not compensate by explaining either parameter. It never names service_name or user_google_email, nor does it clarify expected formats, allowed values, or how to choose the service. The phrase 'different credentials' only weakly hints at user_google_email, leaving the agent to guess at 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 tool's purpose: 'Manually initiate Google OAuth authentication flow.' It identifies the specific action and resource, and distinguishes itself from the long sibling list by being the explicit authentication entry point for Google Workspace tools.
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 when to use the tool with three concrete conditions and directly advises that in most cases the agent should simply call the needed Google Workspace tool instead. It also covers the failure/retry scenario, making the when-to-use and when-not-to-use guidance unambiguous.
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?
Annotations already carry the safety profile (readOnlyHint=false, destructiveHint=true), so the bar is lower. The description adds meaningful beyond-schema context: the atomic all-or-nothing guarantee of the batch, the explicit warning about 'index calculation errors,' and the phased-workflow strategy to avoid them. It doesn't cover rate limits or failure-mode details, but the atomicity and index-hazard disclosure are genuinely additive.
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 long, but the tool is genuinely complex (25+ operation types), and each section earns its place: purpose, sibling routing, then a structured workflow with a concrete example. The example batch is verbose but high-value, since it demonstrates the exact operation-dict format. Purpose and routing are front-loaded, though the workflow section could be tightened slightly.
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 output schema exists, so return values need no explanation; annotations cover the safety profile. For a tool of this complexity, the description addresses the single most dangerous failure mode (index calculation errors) with a prescriptive workflow. It does not explicitly compare against other doc-mutation siblings like insert_doc_elements or modify_doc_text, which would round it out, but the critical-path guidance 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 description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining how to use the most error-prone parameter (operations): the end_of_segment=true pattern, a concrete example batch showing the exact operation-dict shape, and guidance on when index math is needed versus avoided. This operational meaning complements the schema's per-field documentation rather than repeating it.
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 opening sentence states a specific verb ('Executes'), resource ('low-level document operations'), and scope ('single atomic batch update') that distinguishes it from the single-operation doc tools in its sibling set. The emphasis on 'multiple' and 'low-level' clearly separates it from higher-level tools like update_doc_headers_footers and modify_doc_text.
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 routing guidance names the alternative tool and the condition that selects it: 'For normal header/footer text, prefer update_doc_headers_footers' and 'Only use create_header_footer here for advanced section-break layouts.' The RECOMMENDED WORKFLOW section further tells the agent exactly when and how to use this tool (phase-based building with end_of_segment=true) versus other approaches.
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?
Annotations already mark readOnlyHint, openWorldHint, and idempotentHint true; the description adds meaningful behavioral detail: membership visibility is governed by the group setting, and 403 is an authorization outcome rather than a malfunction. It also states what entries contain (emails and roles), which helps the caller interpret results.
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 short sentences, each earning its place: purpose, visibility/error interpretation, and output contents with a cross-tool tip. The most important behavioral caveat is front-loaded immediately after the 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 full schema coverage, useful annotations, and an output schema present, the definition is complete. It even addresses the most likely failure mode (403) and gives a pointer for a natural follow-up task (resolving emails to names). Nothing critical is missing.
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% for all three parameters (group_email, max_results, user_google_email), so the schema already carries the semantic load. The description adds no extra parameter-specific meaning beyond the schema, so the 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 uses a precise verb-resource pair: 'List the members of a Google Group', and disambiguates the API family (Cloud Identity Groups API). The title/name alone already says this, so the description reinforces it rather than restates it, and the 403/visibility notes give extra operating 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?
The description explains the usefulness context: if you need to view group membership and understand visibility limitations. It also points to search_directory_people for email-to-display-name resolution. It does not explicitly state alternatives for membership listing, but no close sibling exists, so this is sufficient.
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?
Annotations already signal mutation and destructiveness, and the description adds useful context: a single operation can combine text insertion/replacement with formatting, and end_of_segment avoids index calculation errors. The segment_id warning adds a safeguard about where IDs must come from. The description doesn't enumerate every destructive consequence, but 'replace' plus destructiveHint covers the core risk.
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 with no filler. The main capability is front-loaded, followed by a practical tip and two targeted warnings. Every sentence earns its place.
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?
For a 21-parameter mutating tool, the description covers the main operations, a common failure mode, and the sensitive segment_id case, while the output schema handles return details. It does not explicitly explain deletion via empty-text replacement or all parameter combinations, but the schema covers those mechanics. Overall this is solid but not exhaustive.
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 21 parameters have schema descriptions, so the baseline is 3. The description adds genuinely non-obvious guidance: end_of_segment=true avoids index calculation errors, and segment_id should only come from inspect_doc_structure output, not guessed values. This goes beyond what the schema property descriptions provide.
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 a specific verb and resource: 'Modifies text in a Google Doc.' It clearly distinguishes the tool's capabilities by naming insert, replace, and formatting in a single operation, and the header/footer note helps separate it from 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 explicitly routes ordinary header/footer text to update_doc_headers_footers and warns against passing guessed segment IDs. It also gives concrete when-to-use advice for end_of_segment=true, making the selection and invocation guidance direct.
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?
Annotations already mark the tool read-only and idempotent, and the description adds substantial behavioral context beyond that: it preserves formatting, includes comments by default, preserves anchor text, and exposes suggestion rendering behavior. These details meaningfully inform an agent about what the output will contain.
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-organized into three focused paragraphs, front-loads the core purpose, and uses the second sentence to differentiate from a sibling. Every sentence adds useful information without redundancy or unnecessary padding.
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 a rich input schema and output schema, and the description covers the key behavioral decisions an agent needs: Markdown formatting, comment inclusion, comment modes, and suggestions rendering. No critical calling context is missing given the structured annotations and schema already present.
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 input schema already documents every parameter clearly. The description adds useful high-level context about comment anchor text and Markdown features, but it does not materially deepen the per-parameter semantics 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 tool 'Reads a Google Doc and returns it as clean Markdown' and enumerates the formatting features it preserves. It also explicitly contrasts itself with get_doc_content, making its identity and scope 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 names the sibling alternative get_doc_content and states the deciding difference: plain text versus Markdown-preserving output. It also explains comment behavior and modes, so an agent understands when this tool is appropriate and when another tool would be better.
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?
Beyond the readOnly/idempotent annotations, the description discloses mode-dependent return behavior, the 1-hour URL validity, and the per-file-type export rules. It clearly explains what happens for Google native files versus other files, which is exactly the kind of context an agent needs.
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 organized with a clear opening sentence followed by concise mode and format bullets. Every sentence adds necessary behavioral or usage detail, with no filler or repeated schema content.
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, the description covers all essential call-time decisions: mode behavior, native-file export mapping, default formats, and the fact that original formats are used for non-native files. An output schema exists for return values, and annotations cover the safety profile, so nothing critical is missing.
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 baseline is 3. The description adds value by mapping export_format values to specific source file types (Docs, Sheets, Slides) and clarifying defaults per type, which the schema only partially conveys. This pushes it above baseline without fully re-explaining parameters like file_id and user_google_email.
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 immediately states a specific action and resource: 'Downloads a Google Drive file and saves it to local disk.' It then distinguishes its behavior by mode and file type, making it clearly different from siblings like get_drive_file_content or get_drive_shareable_link.
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 gives clear context for when different behaviors apply: stdio mode returns a local path, HTTP mode returns a temporary URL, and file type determines export formats. It does not explicitly name alternative tools or exclusion conditions, but the provided mode and format guidance is enough for an agent to decide when to use this 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?
Beyond annotations (destructiveHint=true, readOnlyHint=false), the description discloses rich behavioral detail: automatic creation when absent, content replacement when present, and the failure mode of the low-level alternative. The phrase 'its content is replaced' explicitly states what gets destroyed, and the reassurance that no separate creation step is needed adds prerequisite context the annotations cannot convey.
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 front-loaded with the core purpose and 'default tool' designation, followed by a targeted warning about the sibling alternative and a bulleted breakdown of behavior. Every sentence earns its place; the bullets and closing reassurance are compact and scannable rather than redundant.
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 a moderate 5-param tool with a full output schema, safety-relevant annotations, and a large sibling list, the description covers the decision-relevant aspects completely: when to use, when not to use, what happens on both existence paths, and that no prerequisite steps are required. The one ambiguity (which header/footer_type is affected) is already resolved by the schema's parameter descriptions.
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 marginally reinforces parameter meaning by referring to 'content' as 'desired content' and 'header/footer text,' but it does not add format, syntax, or domain details beyond what the schema already documents.
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 opening sentence states a specific verb+resource combination: 'creates or updates header/footer text in a Google Doc.' The description further differentiates from its nearest sibling by explicitly naming batch_update_doc as the wrong tool for this job, so an agent can disambiguate without inspecting schemas.
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 declares 'This is the default tool for header/footer content' and gives a clear exclusion: 'Do NOT use batch_update_doc with create_header_footer just to set header/footer text.' It also explains the condition that selects the alternative (advanced section-break workflows) and why it fails for the common case, leaving nothing to inference.
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 destructiveHint already being true, the description adds crucial behavioral detail: with merge=False, 'any existing file omitted from files is permanently deleted.' This tells the agent exactly what gets destroyed and emphasizes permanence, going beyond the annotation.
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 and front-loaded. The first sentence states the core purpose, and the second sentence explains the key behavioral distinction. Every sentence earns its place with no 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 the output schema exists and all parameters are documented in the input schema, the description covers the essential behavioral context: creation/update, merge mode, and destructive replacement mode. Nothing critical is missing for an agent to call this tool 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 the baseline is 3, but the description adds value by explaining that files are merged 'by file name' and that other files remain untouched. It also clarifies the permanent deletion consequence of merge=False, which deepens the meaning of both `files` and `merge`.
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 opens with a specific verb and resource: 'Update or create files in a script project.' This clearly identifies the tool's object of action and distinguishes it from siblings like get_script_content or create_script_project. The merge/replace detail further clarifies 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context for the two modes: default merge behavior versus merge=False for full replacement. It does not explicitly name sibling alternatives such as create_script_project or get_script_content, but the intended use case is evident from the wording.
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?
The annotations already mark this as readOnly, idempotent, and non-destructive. The description adds substantive behavioral context beyond those hints: it defines total_length as the maximum safe insertion index, warns against inventing segment IDs, and explains the conditional behavior of tabs in the output. It makes the tool's inspection semantics and safe usage bounds explicit.
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 lengthy but well-organized into labeled sections, bullets, and numbered steps, which makes the complexity navigable. It front-loads the core purpose and critical usage warning, and most sections earn their place by conveying actionable workflow detail. Some redundancy exists between the 'CRITICAL FOR TABLE OPERATIONS' callout and the repeated workflow steps, but it does not become noise.
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 is exceptionally complete. It covers not just what the tool returns but how to consume those outputs in real workflows (table insertion indices, formatting ranges, header/footer segment IDs). Nothing an agent needs to call this tool correctly is missing.
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, so the baseline is 3. The description adds extra meaning by explaining how the detailed parameter changes the output (elements with start_index/end_index and text_preview) and that tab_id controls whether a list of tabs is returned. This goes beyond the schema's minimal parameter 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 clear verb+resource combination: 'inspect' + 'document structure', and goes further to state the primary purpose: finding safe insertion points and understanding layout. It differentiates itself from siblings like debug_table_structure by emphasizing safe index discovery and document-wide structure inspection, not low-level table debugging.
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 usage guidance is provided in multiple forms: a 'USE THIS FOR' list, a 'CRITICAL FOR TABLE OPERATIONS' mandate to call before creating tables, and workflow steps for table insertion, formatting, and header/footer editing. It also names an alternative (update_doc_headers_footers) for ordinary header/footer text, drawing a clear when-to-use versus when-not-to-use boundary.
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?
Annotations already carry the mutation/destruction signal, and the description adds meaningful behavioral context beyond them: content replacement preserves the existing file ID and social metadata, native Google formats undergo MIME conversion, other files are written back as-is, and append/prepend splice server-side only the new text. No contradiction with the readOnlyHint=false or destructiveHint=true 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 front-loaded with the purpose, then uses dense, purposeful paragraphs for replacement semantics, conversion behavior, and append/prepend mode. Every sentence adds operational value, and the length is proportionate to a 17-parameter mutation tool.
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 100% schema coverage, rich annotations, and an output schema, the description covers the most decision-critical behavior: in-place content replacement, MIME conversion nuances, and append/prepend constraints. It does not need to restate parameter-by-parameter details because the schema already does that.
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 baseline is 3, but the description adds cross-parameter meaning that the schema alone does not make obvious: exactly one of content/file_path/file_url should be provided for content replacement, append/prepend require content and a UTF-8 text file, and source_format interacts with conversion for native Google file types. This goes beyond individual parameter 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 opens with a specific verb-resource pair: 'Updates metadata, properties, and/or content of a Google Drive file.' It further distinguishes this tool from siblings by emphasizing in-place content replacement that preserves file ID, sharing, comments, and links, and by contrasting conversion behavior for native Google files versus other formats.
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 content replacement applies, which content source parameters are mutually exclusive, and what happens for native Google Docs versus plain files. The mode parameter also names concrete alternatives — insert_doc_elements, modify_doc_text, and find_and_replace_doc — for native-doc edits, giving the agent clear 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.

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:

[![google_workspace_mcp MCP server](https://glama.ai/mcp/servers/WorldCentralKitchen/google_workspace_mcp/badges/card.svg)](https://glama.ai/mcp/servers/WorldCentralKitchen/google_workspace_mcp)

Score Badge

Copy to your README.md:

[![google_workspace_mcp MCP server](https://glama.ai/mcp/servers/WorldCentralKitchen/google_workspace_mcp/badges/score.svg)](https://glama.ai/mcp/servers/WorldCentralKitchen/google_workspace_mcp)

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/WorldCentralKitchen/google_workspace_mcp'

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