google-workspace-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Service prefixes and distinct action verbs make most tools easy to tell apart. The only real overlap is that drive_read_file_content can also read Google Docs/Sheets, which partially duplicates docs_read_document and sheets_read_range, but the descriptions clarify the intended use.
Naming Consistency5/5Every tool follows a consistent snake_case service_prefix + verb_noun pattern, such as drive_upload_file, sheets_append_values, calendar_create_event, and gmail_send_message. There is no mixing of conventions or vague naming.
Tool Count4/527 tools is above the typical sweet spot, but the server covers five distinct Google Workspace apps, and no single app has more than 7 tools. The count feels slightly heavy but is reasonable given the broad integration scope.
Completeness4/5Core lifecycle workflows are covered across Drive, Sheets, Docs, Calendar, and Gmail: search/read/create/update/delete are largely present. Notable gaps exist such as Drive move/update, Sheet row deletion, and Gmail trash/label management, but agents can complete primary tasks without dead ends.
Average 4.1/5 across 27 of 27 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto 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
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that this is a non-read-only, non-idempotent, non-destructive operation. The description adds the return value details (id, name, mimeType, webViewLink), implying it creates a new file. However, it does not disclose potential side effects like creating duplicates, permission requirements, or auth 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one core sentence plus a short Returns section. It front-loads the primary purpose and provides essential return information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an upload tool, the description covers the action and the return payload, while the schema covers parameter details and annotations cover safety characteristics. It is complete enough for an agent to use correctly, though it could briefly mention that this creates a new Drive file rather than overwriting an existing one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description itself does not explain any parameters, but the input schema provides clear descriptions for local_path, name, mime_type, and parent_folder_id. The schema carries the parameter-semantics burden, so the description does not need to repeat it; the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Upload a local file to Google Drive.' It clearly identifies the tool's purpose and is distinguishable from siblings like drive_download_file or drive_trash_file, though it does not explicitly name 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 Guidelines2/5Does 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 drive_create_folder or drive_download_file. The intended use is implied by the name and first sentence, but there are no explicit usage conditions, prerequisites, 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?
The annotations already communicate that this is a mutating, open-world operation (readOnlyHint=false, openWorldHint=true), so the description does not need to restate that. It adds some value by specifying the return payload (id, name, webViewLink), but it does not disclose potential side effects, failure modes, or permissions beyond what the schema and annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, direct, and front-loaded with the primary action. Every sentence serves a purpose: the first states the operation and resource, and the second specifies the return format. There is no filler or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create-folder tool, the description covers the core operation and the return value, and the schema and annotations together fill in parameters and mutation intent. The main missing piece is usage guidance around when to choose this over sibling creation tools, but the tool is still sufficiently callable in most straightforward cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not compensate by explaining parameters like parent_folder_id or its default behavior. Although the schema properties have their own descriptions, the tool description itself provides no parameter-level semantic guidance, which is a clear gap for a create operation with a parent folder option.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear, specific action: 'Create a new folder in Google Drive.' It names the exact resource (folder) and verb (create), and the return value specification further clarifies what the tool does. It is easily distinguished from sibling tools like drive_upload_file or docs_create_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 drive_upload_file or sheets_create_spreadsheet. There are no exclusions, prerequisites, or conditions, leaving the agent to infer suitability from the 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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the return contract and confirms folders are supported, but it does not disclose operational details such as permissions requirements, error behavior, or how 'full metadata' interacts with the listed fields. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the action, and every sentence earns its place. The return field list is directly useful for an agent deciding whether this tool satisfies the current task.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with rich annotations and an output schema, the description is nearly complete. The only notable gap is the absence of explicit sibling routing, but the core purpose, input, and return behavior are clearly conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description never explains the required file_id parameter, its source, or its format. Although the nested schema contains a useful description, the context signal reports 0% schema description coverage, and the description itself adds no parameter semantics to compensate for that gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a clear resource ('a single Drive file or folder'), and the output ('full metadata'). This distinguishes it from siblings such as drive_read_file_content and drive_search_files without needing to open 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/5Does 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. It does not mention that file_id typically comes from drive_search_files, nor that file content should be retrieved with drive_read_file_content. Usage context is only implied by 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 indicate the tool is not read-only, not idempotent, and not destructive. The description adds the return value detail and that it appends to an existing document, but it does not mention permissions, error behavior, or consequences of repeated calls beyond what the idempotentHint implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, with the core operation first and return value second. No filler or redundant information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple append operation with schema-covered parameters and an output schema, the description is largely complete. It would benefit from explicit usage routing to siblings and mention of failure conditions, but nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters clearly: text is 'Plain text to append to the end of the document' and document_id is 'The Google Doc ID (from its URL)'. The tool description adds no parameter meaning beyond the schema, so baseline 3 applies despite the reported 0% coverage metric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Append plain text to the end of an existing Google Doc') with a specific verb and resource. It distinguishes itself implicitly from create/read/replace siblings, but does not name any sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: it is for appending to an existing document, which suggests it is not for creating or replacing content. However, there is no explicit guidance about when to choose this over docs_replace_text or docs_create_document.
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 genuine value beyond the annotations by disclosing that trashing is recoverable rather than permanent, which matters for an agent deciding whether to warn a user or offer an undo path. destructiveHint=true and readOnlyHint=false are consistent with the stated behavior, so there is no contradiction. It also names the return payload, though that partly duplicates the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the core action front-loaded and the key nuance (recoverable) in a parenthetical in the same breath. The 'Returns' block is slightly redundant with the existing output schema but is brief and usefully names the confirmed fields. No filler, repetition of annotation flags, or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter mutation tool with annotations covering destructiveness and idempotency, and an output schema covering the return value, the description covers the essentials: what it does, that it is recoverable, and what it returns. It omits minor context such as required scopes/permissions, behavior for missing files, and whether folders are supported, but these are low-stakes at this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description adds no parameter semantics beyond the schema, and the context signal reports 0% schema description coverage for the top-level input object, so the description carried the burden to compensate and did not. Practical harm is limited because the single parameter's meaning is evident from the file_id name and the schema's own property description. The description does not document formats, required scopes, or invalid-ID behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Move a Drive file to the trash') and immediately clarifies scope with 'recoverable, not permanent deletion,' preempting the most common confusion about this operation. The sibling set contains no other trash/delete tool, so there is no ambiguity about which tool this is. The annotation title reinforces the same 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/5Does 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; usage must be inferred from the stated action. The sibling set has no permanent-delete tool, and the description never discusses that alternative, though the 'recoverable' parenthetical implicitly contrasts with permanent deletion. This is adequate but leaves context to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the file lands in My Drive root and specifies the return JSON fields (document_id, title, url), which adds value beyond the annotations. It describes a mutating operation consistent with readOnlyHint=false and destructiveHint=false. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the core action, and contains no filler. The location and return information are in clear, separate statements that earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter create operation, the description covers the core action, the resulting location, and the return format. It does not discuss error conditions or permissions, but the annotations and output schema cover the remaining safety and output expectations. It is mostly complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Per the context signal, schema description coverage is 0%, so the description must compensate for parameter meaning. It clarifies that initial_content is optional plain text, but it does not explain the required title parameter beyond the tool's general purpose. Parameter semantics are mostly left to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Create') and resource ('Google Doc'), and notes the optional initial plain-text content. It is easy to distinguish from sibling tools that read, append, replace, or create spreadsheets. The return section further clarifies what the tool produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context that a new file lands in the account's My Drive root, which helps an agent understand the side effect. However, it does not explicitly mention when not to use this tool or name alternatives such as sheets_create_spreadsheet. Usage is implied rather than directly guided.
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, openWorldHint, and destructiveHint=false. The description adds meaningful context by specifying that it returns a string containing a JSON list of sheet_id, title, index, row_count, and column_count, and by scoping the behavior to 'all sheet tabs.' 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler: the first states the action and scope, the second states the exact return contract. It is 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.
Completeness5/5Given 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 description fully covers the supported operation and expected output. The annotations cover safety and idempotency, the schema covers the single parameter, and the description covers the return shape. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter spreadsheet_id is documented in the input schema as 'The spreadsheet ID (from its URL).' The tool description itself only refers to 'a spreadsheet' and adds no extra detail about how to obtain or format the ID. Since the schema already provides the necessary parameter meaning, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List all sheet tabs in a spreadsheet with their IDs and dimensions.' It clearly names the output fields and distinguishes this from cell-range operations. It does not explicitly contrast with sibling tools, 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving tab-level metadata rather than cell data, and the return format reinforces that. However, it does not explicitly state when to use this tool versus alternatives such as sheets_read_range, nor does it mention any exclusions or prerequisites. Usage guidance remains 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 establish readOnlyHint, idempotentHint, openWorldHint, and non-destructiveness. The description adds that the result is scoped to the authenticated account's access and includes access_role, but it does not mention pagination, rate limits, auth scope requirements, or other operational 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main purpose, followed by a terse return-format note. Every sentence contributes useful information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial zero-parameter, read-only list operation with rich annotations and an output schema, the description is close to complete. It clearly states the returned fields and access scope, though it could optionally clarify pagination or large-result behavior given openWorldHint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no real properties except a required empty 'params' object, so there are effectively no parameters to document. The description adds no parameter details, but none are needed; the baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'List all calendars the authenticated account can access.' It also details the return shape as a JSON list of {id, summary, primary, access_role}, which unambiguously distinguishes this tool from siblings like calendar_list_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need the set of accessible calendars, but it does not explicitly say when to prefer this over alternatives or mention related tools like calendar_list_events. There is no exclusions or '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?
The annotations already flag this as destructive and not read-only, so the description does not need to restate that. It adds meaningful behavioral context: only provided fields are changed, preventing the agent from assuming null values clear fields. It also states the return shape, which is useful 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded. The first sentence states the operation, the second clarifies the update semantics, and the returns line is brief and useful. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema's detailed parameter descriptions and the annotations covering read-only/destructive behavior, the description is largely complete. It covers the key partial-update rule and return format. Minor gaps like error handling or permission requirements exist, but they are not critical for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not enumerate individual parameters, but the schema already provides strong per-field descriptions like 'New start time (RFC3339 or YYYY-MM-DD), if changing it.' The description's 'Only provided fields change' adds a useful cross-cutting rule, but it does not carry the parameter-documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific operation ('Update fields') on a specific resource ('existing calendar event'). The phrase 'Only provided fields change' adds partial-update semantics and helps differentiate this from create_event and delete_event 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when modifying an existing calendar event rather than creating or deleting one. However, it does not explicitly name alternatives or state when not to use this tool, leaving the agent to infer routing 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey destructiveness, idempotency, and non-read-only behavior. The description adds important context beyond those annotations by specifying that cell formatting remains intact and that the operation clears only values. It also documents the return as a JSON confirmation string, which is useful behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, purposeful sentences. The core behavior is stated first, followed by the return type, with no redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple clear-range operation, the description combined with annotations and schema covers the essential information: what is cleared, what remains, that it is destructive yet idempotent, and the confirmation return. It does not discuss edge cases like invalid ranges or permissions, but that level of detail is not necessary for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description itself does not elaborate on individual parameters, but the input schema provides clear descriptions for both 'range' and 'spreadsheet_id', including format and source. Since the schema covers parameter meaning adequately, the description does not need to add more; a baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'clear' and resource 'range', and clarifies that only values are removed while formatting is preserved. This distinguishes it from siblings like sheets_write_range, sheets_append_values, and sheets_read_range, 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (clear cell contents while preserving formatting) but provides no explicit alternatives or when-not-to-use conditions. An agent can infer the usage from the wording, but the tool does not proactively route to a sibling like sheets_write_range.
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. The description adds value by specifying the return contract (JSON with range and values as a 2D array) and the caveat that empty trailing cells are omitted by Google's API. This is useful behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs with no filler. The primary verb/resource statement is front-loaded and the return shape is presented in a compact structured block.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation, the description, annotations, and schema cover the core workflow and return value. It is slightly incomplete only in lacking explicit alternative routing or error/format caveats beyond empty trailing cells, but nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain spreadsheet_id or A1 notation parameters, but the input schema's $defs provide descriptions for both, including the example format and source of the spreadsheet ID. This meets the baseline for schema-supported parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Read cell values from a range in a Google Sheet') that clearly identifies the operation. This distinguishes it from sibling write/append/clear tools without needing to open 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The read-only wording implies the tool is for retrieving data, but it does not explicitly state when to prefer it over alternatives such as sheets_write_range, sheets_list_tabs, or drive_read_file_content. There is no when-not-to-use or exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the annotations by explicitly stating that the deletion is permanent, that attendees are notified of cancellation, and that the return value is JSON confirming deletion. This is meaningful behavioral context beyond the destructiveHint and idempotentHint flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two terse sentences with no filler. The primary purpose and the most important side effect are front-loaded, and the return note is cleanly separated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, destructive, idempotent delete operation, the description covers the permanent nature, the attendee notification side effect, and the return shape. The schema documents the parameters, and annotations cover the safety profile. No material gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description itself contributes no parameter-specific guidance, but the schema provides clear descriptions for both parameters: event_id is 'The event ID to delete' and calendar_id is 'Calendar ID, or primary for the main calendar.' Since the schema covers parameter meaning, the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Permanently delete'), a specific resource ('a calendar event'), and a key consequence ('attendees are notified of cancellation'). This clearly differentiates it from siblings like calendar_create_event and calendar_update_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied by the verb 'delete' and the sibling list: use this when you need to remove a calendar event. However, there is no explicit when-to-use, when-not-to-use, or comparison to alternatives such as calendar_update_event.
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 destructiveHint=true; the description adds that the operation touches every occurrence and returns a JSON count of changes. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The purpose is front-loaded and the return format is given in a compact second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, annotations, and existing schema together provide enough for a simple mutation tool: what it does, that it is destructive, and what it returns. It could add explicit usage alternatives, but nothing critical is missing for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The reported schema-description coverage is 0%, so the description needed to carry parameter semantics. It only loosely implies find_text and replace_text; it does not explain document_id, match_case, or the default case-sensitive behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Replace'), a precise scope ('all occurrences ... throughout a Google Doc'), and the resource. This clearly distinguishes the tool from reading, appending, creating, or deleting docs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It conveys the intended use case: global find-and-replace within a Google Doc rather than read/append/create operations. However, it does not explicitly name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as a write operation (readOnlyHint=false); the description adds the key behavioral guarantee that no email is sent and discloses the returned draft/message ids. This is useful context beyond the structured annotations 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with the core action front-loaded and no filler. The return-type line is short and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create-draft operation, the description plus the annotated safety profile and output schema are largely sufficient. It could mention routing to gmail_send_message for actual sending, but that is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description offers no parameter guidance, and the context signal reports 0% schema description coverage for the top-level `params` parameter, so the description needed to compensate but did not. The nested schema does label to/subject/body, which partially mitigates the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Create a draft email' and immediately scopes it with 'without sending it,' distinguishing it from sibling gmail_send_message. The intent 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'without sending it' qualifier gives clear context that this tool is for preparing unsent messages, which implicitly separates it from gmail_send_message. It does not explicitly name an alternative or state when-not-to-use, 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?
Annotations already signal a non-readonly, non-idempotent mutation; the description adds a valuable side effect by stating that attendees are automatically emailed and that no separate send step exists. It also discloses the return fields. This exceeds annotation coverage, though it does not discuss authorization or calendar 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is short, with the action front-loaded, a critical side-effect in the second sentence, and a compact return specification. It contains no filler and does not redundantly restate schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a nested parameter schema that already explains formats, defaults, and nullable fields, the description covers the high-level operation, side effects, and return value. It does not mention calendar discovery for non-primary calendars, but that is a minor omission given the schema and sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description itself adds no parameter-level detail. However, the nested EventCreateInput schema fully documents each property, including start time formatting, all-day vs timed events, calendar_id default, and attendee_emails, so the agent can still invoke the tool correctly. The description neither repeats nor enhances this schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence uses a specific verb and resource ('Create a new calendar event') and clearly scopes the operation with optional attendee invites. This distinguishes it from sibling tools such as calendar_update_event, calendar_delete_event, and calendar_list_events 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context that this is the creation entry point and warns that attendee invitations are sent automatically with no separate send step, which prevents a redundant email step. It does not explicitly name alternatives or state when not to use it, but the create/update/delete sibling set makes the intended use obvious.
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 context beyond annotations: it can return upcoming events or date-ranged events, supports text filtering, and enumerates the exact fields in the returned JSON list. This gives the agent a clear model of what the call will produce.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core behavior, and the second sentence details the return format. Every sentence contributes information not already obvious from the tool name or schema. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Between the description, detailed schema, and read-only annotations, the tool is sufficiently specified for correct invocation. The return fields, filtering behavior, and time-bounds semantics are covered. A minor gap is the lack of explicit routing guidance relative to sibling tools, but that is not essential for a straightforward read-only listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the context signal reports 0% schema description coverage, the nested schema actually provides detailed descriptions for all five parameters, including defaults and RFC3339 format. The description adds extra meaning by framing query as text filtering and time_min/time_max as 'upcoming or date-ranged', which helps the agent map intent to parameters. It does not discuss calendar_id or max_results, but the schema already covers those clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List upcoming or date-ranged events on a calendar'. It also adds the optional text-filter capability, which distinguishes it clearly from sibling tools like calendar_list_calendars and calendar_create_event. Even without naming siblings, the purpose is unambiguous and scoped to events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing the read-only listing behavior, and the sibling set makes the contrast with create/update/delete tools clear. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it, such as for calendar metadata listing.
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 the return format as a JSON string with the saved path and byte size, and mentions the error case when export_mime_type is missing. This adds meaningful behavior beyond the annotations' readOnly/idempotent hints, though it doesn't cover details like overwrite behavior or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core action in the first sentence and return behavior in a short second section. Every sentence earns its place; there is no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Together with the detailed input schema, the description provides enough context to call the tool correctly, including the export requirement and return shape. Minor gaps like overwrite behavior and permission requirements exist, but they are not critical for selecting or invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already documents file_id, destination_path, and export_mime_type, the description adds important semantics around export_mime_type: it is required for Google-native files and its absence produces an error. This enriches the parameter's meaning beyond the raw schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action—'Download a Drive file to a local path'—and adds the export behavior for Google-native files. This distinguishes it from sibling tools like drive_read_file_content or drive_get_file_metadata, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context: use when downloading a Drive file to a local path, and when exporting native files. However, it does not explicitly state when not to use it or mention alternatives such as drive_read_file_content for reading file content without downloading.
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 that the tool is read-only and idempotent. The description adds meaningful behavioral context by explaining accepted query forms, the JSON return shape, and the pagination contract via next_page_token. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core action in the first sentence and the query modes and return format following efficiently. Every sentence earns its place; no filler or repetition is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool, the description covers query modes, return keys, and pagination behavior. Combined with the detailed schema and safety annotations, nothing essential is missing for an agent to correctly select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The nested DriveSearchInput schema already thoroughly documents query, page_size, page_token, and include_trashed with examples and constraints. The description adds the high-level plain-text-vs-raw-query distinction, but that is also stated in the schema, so the description provides little parameter meaning beyond structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search for files and folders in Google Drive.' This clearly distinguishes the tool from sibling content-retrieval and mutation tools such as drive_read_file_content, drive_upload_file, and drive_trash_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage context: plain text is matched against file names, while raw Drive query strings support advanced filtering by MIME type, folder, date, etc. It does not explicitly name alternatives or when-not-to-use cases, but the intended selection context is clear enough.
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 it read-only, idempotent, and non-destructive. The description adds useful behavioral detail by specifying the plain-text body and the exact fields returned. It stops short of a 5 because 'full content' is slightly overbroad and attachments/HTML handling is not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with the purpose first and a scannable return list second. No filler or repetition of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter read-only operation, the annotations, and the output schema, the description provides everything needed to call the tool correctly. The only minor gap is explicit sibling routing, which is not essential for invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description does not mention the message_id parameter, but the input schema's nested property documents it as the Gmail message ID from a list/search result. With that schema coverage, the parameter is adequately explained; the description adds no further semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get the full content of a single Gmail message') and names the resource (Gmail message), then clarifies the returned body is plain-text. The listed fields (from, to, subject, date, body, labels) distinguish it from siblings like gmail_search_messages and gmail_list_labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool to use when a single message's full content and plain-text body are needed. The schema's message_id description ('from a list/search result') reinforces that the ID comes from a prior search/list, but the description itself does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the call as a non-read-only, non-idempotent mutation. The description adds the important behavior that the send happens immediately with no API-side confirmation and instructs user confirmation, plus it discloses the return payload. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, focused sections lead with the action, follow with the safety/usage caveat, and finish with return value. No filler or duplication of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a side-effectful send tool, it covers what the call does, the immediate/no-confirmation behavior, the needed user confirmation, and the return format. Combined with the schema descriptions, an agent has everything needed to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description itself adds no parameter-level detail, but the nested input schema documents all five fields (to, cc, bcc, body, subject) with descriptions and requiredness. The top-level params wrapper is unnamed in the description, so the schema carries the burden; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence names a specific action ('Send... an email') and the account scope ('authenticated Gmail account'), and the second sentence contrasts it with draft/confirmation flows. This clearly distinguishes it from siblings like gmail_create_draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the key usage condition (send immediately, no draft/confirmation) and instructs the agent to confirm intent before calling. It does not explicitly name alternative tools or spell out when to prefer gmail_create_draft, 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?
Annotations already indicate this is a write operation and not destructive. The description adds useful behavioral context beyond annotations: the new file is placed in the account's 'My Drive' root, and the return value is a JSON string containing spreadsheet_id, title, and url. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. The key action and optional capability are in the first sentence, followed by placement guidance and return format. There is no wasted text; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create-spreadsheet tool, the description is complete: it states what is created, where it is created, how to handle the folder-location edge case, and what the return value contains. The annotations cover safety and idempotency, so no additional behavioral disclosure is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents title and sheet_names well, so the description does not need to repeat parameter details. The description does reinforce that named tabs are optional ('optionally with named tabs') and mentions title in the return value, but it does not add substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create a new Google Sheets spreadsheet, optionally with named tabs.' This clearly distinguishes it from read/write/append/clear sheet tools and from drive file upload tools. It also mentions the optional named-tab capability, which matches the sheet_names parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear placement context: the file lands in 'My Drive' root, and if a specific folder is needed, a follow-up move should be used. It names an alternative approach, though it does not fully specify the exact sibling tool to call for the move. This is clear context but not a fully exhaustive when-to-use guide.
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 it read-only, idempotent, and non-destructive; the description goes further by disclosing the lossy extraction behavior (tables/images/formatting dropped), reading order, and truncation behavior with max_chars. It also states the exact return shape, which is useful 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose in the first sentence, key limitation in the second, and return contract in the final block. No filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation, the description covers the core behavior, limitations, truncation semantics, and returned fields. Combined with the input schema's parameter descriptions and the read-only annotations, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description ties max_chars to the returned truncated flag and mentions truncation, adding modest semantic context. The schema already provides descriptions for document_id and max_chars, so the description does not substantially clarify parameter syntax or source beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Read the plain-text content of a Google Doc.' It also clarifies what is not preserved (tables, images, rich formatting), which distinguishes this from richer document read or spreadsheet tools 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly establishes this is for extracting paragraph text in reading order and explicitly warns that tables/images/rich formatting are not preserved, which implies when not to use it. However, it does not name alternative tools such as drive_read_file_content or sheets_read_range for structured content.
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 cover the safe, read-only, idempotent nature of the tool. The description adds useful behavioral details beyond that: it returns a JSON list rather than a single object, and it includes both system and user-created labels rather than only user-defined ones.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with a clear scope statement followed by a concise return format. There is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, no-argument listing operation, the description covers scope and return shape, while annotations cover safety and idempotence. 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no actual parameters apart from an empty required 'params' wrapper, so there are zero meaningful parameters to document. The baseline of 4 applies because the schema is self-explanatory and no parameter-level description is necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List all Gmail labels', and adds meaningful scope by noting both system labels like INBOX and user-created ones. This clearly distinguishes it from sibling tools that operate on messages, drafts, calendars, or drives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is strongly implied: use this tool when you need the full set of Gmail label IDs/names/types. There is no sibling tool for listing labels, so an explicit alternative is unnecessary, though the description stops short of stating exactly when an agent should prefer this over other Gmail operations.
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, idempotent, and non-destructive. The description adds useful behavior beyond that: it returns only lightweight summaries with specific fields and steers the agent to gmail_get_message for full content. It does not disclose pagination or auth requirements, but those are minor given the strong annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: purpose first, return shape second, and the gmail_get_message alternative last. The final 'Returns: str: JSON list of message summaries' is slightly redundant with the earlier sentence but still adds the concrete return type and does not waste space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search/list tool, the description plus schema and annotations are complete. It specifies what the tool does, what results look like, what parameters exist, and when to switch to gmail_get_message. Nothing an agent needs to safely and correctly invoke this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds only the high-level phrase 'using Gmail's search syntax' and does not explain query, label_ids, or max_results. However, the schema's $defs provide thorough descriptions for all three nested parameters, so the schema carries the parameter-semantics burden. Even though the top-level coverage signal is 0%, the actual nested schema is detailed enough to invoke correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search or list Gmail messages using Gmail's search syntax.' It also clarifies the scope of results ('lightweight results') and names the sibling tool for full bodies, so an agent can distinguish it from gmail_get_message 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use gmail_get_message when the full body of a specific message is needed, giving a clear alternative and a condition for choosing it. The phrase 'Search or list' also tells the agent this is the appropriate tool for both query-based search and recent-message listing.
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=false. The description adds valuable behavioral context: Google Docs export as plain text, Sheets as CSV, Slides as plain text, binary files rejected, and returned text is truncated to max_chars. It also discloses that errors are returned as messages rather than thrown. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear one-line purpose, a compact breakdown of format handling, an explicit exclusion with alternative, and a concise Returns section. Every sentence carries useful information and no filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers supported formats, unsupported types, the alternative tool, truncation behavior, and return format. It is complete for a read-only text extraction tool. A minor gap is the lack of guidance on when to use this over sibling document/sheet readers like docs_read_document or sheets_read_range, but this is not critical given the clear purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema's nested definitions already describe file_id and max_chars, but the top-level parameter coverage is reported as 0%. The description compensates by explaining that max_chars truncates returned text and by describing the conversion behavior that affects what content is read. It does not add much about file_id, but the schema covers that; overall the description supplements the schema meaningfully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Read the text content of a Drive file directly into the conversation') and immediately clarifies scope by listing supported formats (Docs, Sheets, Slides, text files). It also explicitly distinguishes itself from drive_download_file by noting binary files are not supported here, so an agent can tell tools apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit alternative for unsupported binary files: 'use drive_download_file to save them locally instead.' It also explains what kinds of files are read directly. However, it does not mention when an agent should prefer this over docs_read_document or sheets_read_range, so guidance is incomplete but not absent.
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 annotations, the description discloses the non-destructive nature, the API's end-finding behavior, and the return value (updated_range). This is meaningful operational context that an agent needs to predict 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core action, then differentiates from the sibling, then states the return format. Every sentence serves a purpose with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With the annotations, input schema, and output description, the tool is fully understood for correct invocation. The description covers what the operation does, how it differs from overwriting, and what the response will contain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context like 'rows' and 'table/range', but the underlying input schema already contains clear descriptions for spreadsheet_id, range, and values. The description does not need to repeat them, but it also does not add substantial new parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Append rows after the last row of existing data in a table/range.' It also explicitly contrasts with sheets_write_range, making the tool's role clear among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It directly says when to use this tool versus sheets_write_range: 'this never overwrites existing rows' and the Sheets API 'finds the end of the data and inserts after it.' This gives an agent an explicit decision rule.
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 include destructiveHint=true and readOnlyHint=false, and the description reinforces and explains the destructive behavior: the overwritten area is determined by the number of rows/columns in values starting at the top-left of range. It also discloses the return fields, going 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized: core behavior first, alternative tool second, return format last. Every sentence provides necessary information without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward write operation, the description covers the operation, the overwrite semantics, the alternative tool, and the return value. Combined with the schema and annotations, an agent has enough context 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds useful semantic meaning to values and range by explaining how they interact, but it does not mention spreadsheet_id at all. Given the reported 0% schema description coverage, the description only partially compensates for parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Write values into a range') and the key consequence ('overwriting whatever is currently there'). It clearly distinguishes this tool from sibling sheets_append_values by emphasizing the difference between overwriting and appending.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use sheets_append_values instead: when adding new rows without overwriting existing data. This is direct when-to-use versus when-not-to-use guidance, and it also clarifies how the values array determines the overwrite extent.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/hoaaah/Google-Workspace-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server