orieg/gws-connector

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.3.3
Disambiguation5/5
Each tool is namespaced by service (accounts, mail, sheets, docs, drive, cal) and has a distinct action. Even similar-sounding tools like accounts.add vs accounts.reauth are clearly differentiated by description. No significant overlap exists.
Naming Consistency5/5
All tools follow the consistent gws.<service>.<action> pattern with snake_case verbs (create, list, read, search, etc.). Minor variations like get_profile vs list_labels are appropriate to the context and do not break the convention.
Tool Count4/5
30 tools is a large number, but it is justified by covering six distinct Google Workspace services (Accounts, Mail, Sheets, Docs, Drive, Calendar). Each tool serves a specific purpose, and the count is not excessive given the scope.
Completeness4/5
The tool set covers account lifecycle, Gmail read/search/draft/send, Sheets read/write, Docs create/read/edit, Drive search/list/read, and Calendar list/read/create. Minor gaps exist such as Drive file upload/delete and Calendar update/delete, but core workflows are well supported.
Average 3.9/5 across 30 of 30 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on August 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 4 times in the last 30 days.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation Contradiction: The annotations set destructiveHint=false, indicating the tool is not destructive. However, the description states 'This tool irreversibly modifies user content,' which implies a destructive or harmful side effect. Additionally, the warning about calling it on documents you did not create suggests it can modify existing content, contradicting the schema's capabilities and the destructiveHint annotation. This is a serious inconsistency.
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 first two sentences are concise and informative. However, the third sentence is confusing and overstates the tool's risk ('irreversibly modifies user content') and includes a nonsensical instruction about documents not created in this session. This sentence wastes words and detracts from the overall clarity, so the description does not earn 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?
With no output schema, the description should at least hint at what the tool returns or how the result is surfaced, but it does not. The tool is simple, but the misleading safety warning reduces completeness. The description leaves the agent without a clear understanding of the full behavioral contract, such as whether a document ID or URL is returned after creation.
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 covers all three parameters with 100% description coverage. The description adds no new semantic information about parameters; it merely echoes the schema's note that initial_text inserts at the start of the body. Since the schema already documents the parameters clearly, 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 primary purpose is clearly stated: 'Create a new Google Doc.' This distinguishes it from sibling tools like gws.sheets.create. However, the subsequent warning about 'documents you did not create' introduces confusion about whether the tool can operate on existing documents, which is not supported by the schema. This muddies an otherwise clear purpose.
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. The only usage-related instruction is to confirm intent before calling it on documents not created in this session, which is misleading because the tool has no parameter for targeting an existing document. The description does not provide clear context, exclusions, or alternative tool references.
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 adds no behavioral details beyond the readOnlyHint annotation. It does not disclose what kind of content is returned (e.g., text vs binary) or any file type limitations, leaving important behavioral aspects unstated.
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 conveys the action and resource. There is no unnecessary wording or repetition.
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 operation, the description is minimally adequate but lacks contextual details such as output format, supported file types, or any caveats. The annotations and schema cover read-only behavior and parameters, but the description itself remains thin.
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 documented. The description adds no additional meaning about fileId or account; it merely repeats the overall purpose. This meets the baseline 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 clearly states the tool reads a file's content from Google Drive, using a specific verb and resource. It distinguishes from sibling tools like gws.docs.read and gws.sheets.read_range by specifying 'file' and 'Google Drive'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It does not mention that fileId is required, nor does it reference sibling tools like gws.drive.search for finding files first.
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 that it is a non-read-only, non-destructive, non-idempotent operation. However, the description adds no additional behavioral context such as auth requirements, side effects, or return behavior, providing no value 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is slightly redundant with the tool name but remains clear and front-loaded.
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 description is underspecified for a create operation. It does not mention the return value (no output schema), potential side effects beyond creation, or any prerequisites, leaving an agent without enough context to fully anticipate the tool's behavior.
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 7 parameters having descriptions. The tool description adds no extra parameter meaning, but the schema fully documents each parameter, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new calendar event' clearly states the verb (create) and resource (calendar event), distinguishing it from siblings like get_event and 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the creation action but the description does not explicitly state when to use this tool vs alternatives (e.g., get_event, list_events) or provide any 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?
The description adds no behavioral context beyond the annotations: it only states 'Search for files,' which is already implied by the tool name. Annotations already declare readOnlyHint and openWorldHint, so the description provides no additional insight into return formats, pagination, or limitations.
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, direct sentence with no filler words. It front-loads the action and resource, making it highly 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?
With a 3-parameter tool, full schema coverage, and read-only annotations, the description is mostly sufficient. However, the absence of an output schema and any mention of return values leaves a small gap, as does the lack of distinction from list_folder.
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 includes detailed descriptions for all three parameters (query example, account default, maxResults default), so the description does not need to compensate. The description itself adds no parameter-specific meaning, but schema coverage is 100%.
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') and resource ('files in Google Drive'), making its function immediately clear. It distinguishes from sibling tools like read_file (individual file access) and list_folder (browsing a folder).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention exclusions or relationships to other Drive tools, such as using list_folder for browsing a directory.
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 indicate readOnlyHint=false and destructiveHint=false, but the description adds no additional behavioral context. It does not mention side effects, label uniqueness, potential nested folder behavior, or whether existing labels with the same name are overwritten or cause errors. The description provides zero value beyond the annotations, which already flag it as a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for the simplicity of the operation, conveying purpose in minimal space.
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 create operation with rich annotations and full schema coverage, this description is minimally adequate. However, it omits context such as what the label is used for, any return value, or how it fits into the broader Gmail workflow. Given the low complexity and support from schema/annotations, a 3 is fair.
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 (name, account, textColor, backgroundColor) having a clear description. The tool description itself does not add parameter-level meaning, so the baseline of 3 is appropriate given the schema 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?
The description clearly states the action ('Create') and the resource ('a new Gmail label'). It is specific and distinct from sibling tools like list_labels, which reads labels, and create_draft, which creates emails. The verb+resource structure unambiguously conveys 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool or how it relates to alternatives. There is no mention of prerequisites (e.g., needing an account), best practices, or exclusions. The description merely states the action without contextualizing it within a workflow.
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 only says 'List files', which is consistent with the readOnlyHint=true annotation but adds no additional behavioral context (e.g., returns metadata only, non-recursive, pagination behavior). The annotations already declare the operation safe (readOnly, non-destructive), so the description contributes little beyond that. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, no filler, and immediately states the action at the beginning. It is appropriately brief.
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 three optional parameters and no output schema, the description is sufficient for an agent to understand the tool's role and invoke it, especially with the schema providing default behaviors (folderId defaults to root, maxResults defaults to 50). It may not explain recursion or return format, but these are not essential given the tool's simplicity and the sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for account, folderId, and maxResults, so the schema carries the parameter semantics. The description does not repeat or elaborate on these parameters; it only mentions 'Drive folder', which maps to folderId. No additional meaning is added. 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 exact operation: 'List files in a Drive folder.' This clearly identifies the resource (files in a folder) and the action (list), and distinguishes from sibling tools like gws.drive.read_file (content access) and gws.drive.search (query-based retrieval). However, it does not explicitly name these alternatives or state exclusions, so it is clear but not fully sibling-aware.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when the goal is to enumerate the contents of a specific Drive folder, but gives no explicit guidance on when to choose this over gws.drive.search or gws.drive.read_file. There are no statements of prerequisites or conditions. No alternative is 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 already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no additional behavioral context beyond what annotations provide, such as return format nuances or side effects. With annotations covering the safety profile, a score of 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?
The description is a single, front-loaded sentence that wastes no words. It directly states the tool's purpose without extraneous information.
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 there is no output schema, the description could better explain what 'full content' includes (e.g., headers, attachments, body). The format parameter gives some hint, but the description does not elaborate on return values or error behavior, leaving moderate gaps for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with clear descriptions for all three parameters, including format options and the default account behavior. The description itself adds no parameter information, but the schema carries the full burden, 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 clearly states the action ('Read') and the resource ('the full content of an email message'), which distinguishes it from sibling tools like read_thread (which reads a thread) and search (which finds messages). It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. It does not mention any exclusions, prerequisites, or cases where a different tool (e.g., read_thread or search) 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=true, openWorldHint=true, and destructiveHint=false. The description adds the time-range scoping but does not disclose additional behaviors like pagination, default calendar, or that it accepts search queries (q). Since annotations cover safety profile, 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 sentence with no filler or redundant information. It is front-loaded and immediately conveys the core function.
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 6 parameters fully described in the schema and annotations indicating a safe read operation, the description is adequate for an agent to understand the tool's core purpose. It does not explain return values, but no output schema exists; however, the schema and annotations compensate for most gaps. A slightly more detailed description with alternative tool references would push this to 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a clear description. The description adds no extra meaning beyond the schema; it simply restates the time-range requirement. Baseline for high schema coverage is 3, which 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 'List calendar events within a time range' clearly specifies the verb (List), the resource (calendar events), and the scope (within a time range). It distinguishes from sibling tools like gws.cal.get_event (single event), gws.cal.create_event (create), and gws.cal.list_calendars (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of using gws.cal.get_event for a single event or how this differs from listing calendars. The only implied usage is that it lists events over a time range, but no exclusions or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive, non-idempotent operation. The description adds that plain text and HTML bodies are supported, but does not disclose auto-detection behavior, draft persistence, or return value details. This is adequate given the annotations, but not particularly 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 that leads with the action and includes only essential supporting detail about body formats. No wasted words; very efficient.
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 8 parameters and no output schema, the description provides basic purpose but omits context on return values, default account behavior, and contentType auto-detection. It is sufficient for a straightforward invocation but leaves some ambiguity for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with well-described parameters. The description's mention of plain text and HTML bodies maps directly to the contentType and body parameters, adding minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Create an email draft.' It clearly distinguishes from sibling tools like send_draft and modify_message by focusing on the creation of a draft rather than sending or modifying.
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 composing emails, but it does not explicitly state when to use this tool over alternatives such as send_draft or read_message. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only (readOnlyHint=false), so the write nature is known. The description adds the behavioral nuance that the default applies when no account is specified, but does not disclose persistence, error behavior, or broader side effects, which would be valuable for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence precisely states the tool's function without waste. 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 simple one-parameter tool with no output schema and clear sibling context, the description is sufficient. It could benefit from mentioning whether the default is persistent or session-scoped, but the current wording is adequate 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?
The schema covers 100% of the parameter (account) with a clear description, so the baseline is 3. The tool description adds no additional parameter detail 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 uses a specific verb+resource ('Set the default account') and clarifies the scope ('used when no account is specified'). It clearly distinguishes from sibling tools like add, remove, and reauth, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you want to set a default account) but provides no explicit guidance on alternatives or exclusions. Sibling names are distinct, so context helps, but there is no direct 'use this instead of X' statement.
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 destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral context beyond 'full details' — it does not mention required identifiers, return structure, or any side effects. No contradictions 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, compact sentence that directly states the tool's purpose without extraneous words or repetition. It is well-structured and immediately understandable.
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 with no output schema and high schema coverage, the description is sufficient. It clearly indicates the function (get full details) and context is implied by the resource type. It could benefit from noting that an eventId is required, but that is already in the schema, so the description remains 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%, with all three parameters (account, eventId, calendarId) having clear descriptions. The tool description does not add further parameter-level meaning, so the schema carries the load. 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 'Get full details of a calendar event' uses a specific verb ('Get') and resource ('calendar event'), clearly indicating it retrieves detailed information for a single event. This distinguishes it from sibling tools like gws.cal.list_events (which lists events) and gws.cal.create_event (which creates 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving full details of a calendar event, but does not explicitly state when to use it over alternatives or provide context such as needing an eventId from a list operation. The distinction from siblings is not spelled out, so 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by explaining the Gmail search syntax, but it does not disclose behaviors such as pagination, result format, or whether results include full content or just metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the essential purpose and includes a relevant example. It is concise, front-loaded, and contains no superfluous 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 search tool with strong annotations and full schema coverage, the description is mostly complete. The only notable gap is the lack of explicit return-value description, but given the clarity of 'Search emails' and the example, it remains 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?
All three parameters are fully described in the schema, so the baseline is 3. The description adds a small amount of context with the example query, but does not substantially beyond what the schema already provides for account or maxResults.
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 ('Search emails') and further specifies the query syntax with a concrete example. This clearly distinguishes it from sibling tools like read_message and list_labels, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by indicating a search function with Gmail syntax, but it does not explicitly state when to prefer this over alternatives or mention any exclusions. For example, it could clarify that read_message is for retrieving specific messages, but the context is sufficient for basic 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 convey the read-only and non-destructive nature. The description adds minimal behavioral context beyond the scope ('all calendars'), but does not describe output format, pagination, or other side effects. Without annotations, this would be insufficient, but with annotations it is adequate.
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, direct sentence that front-loads the core function. Every word contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, 'List all calendars for the account' is a complete and self-sufficient description. It accurately sets expectations for what the tool returns without needing extra detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single optional parameter 'account' with a helpful description. The tool description adds no further parameter detail, but schema coverage is 100%, 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 clearly identifies the action (list) and the resource (calendars), with a scope ('for the account'). It is unambiguous and naturally distinguishes itself from sibling tools like list_events by naming 'calendars' as the target.
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 its purpose but does not explicitly state when to prefer it over alternatives or what prerequisites exist. It is implied that one would use this to enumerate calendars for an account, but no direct comparison or exclusion is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds no extra behavioral context beyond what is obvious from the name and schema, such as return format or system-label inclusion.
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, efficiently worded sentence that states the tool's purpose without redundancy or unnecessary detail.
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 with a single optional parameter, a one-sentence description is sufficient. The annotations and schema cover safety and parameter semantics, so no further context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'account' parameter documented as 'Account label or email. Uses default if omitted.' The description references 'for the account' but adds no additional 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 'List' with the resource 'Gmail labels' and scope 'for the account', clearly distinguishing it from sibling tools like gws.mail.create_label or gws.mail.read_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating its function, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or alternative 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 and destructiveHint=false, so the safety profile is clear. The description adds the scope ('all messages') but doesn't mention return format, ordering, or potential large response sizes. With annotations providing the core behavioral context, this modest addition is adequate.
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 filler or repetition. It fully communicates the tool's purpose without exceeding necessity.
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, the description covers the essential purpose. There is no output schema, but the description implies a collection of messages. Combined with the schema's format parameter, the context is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (format, account, threadId) already well-documented. The tool description doesn't add additional parameter semantics, 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 is specific and unambiguous: 'Read all messages in an email thread' clearly identifies the verb (read), resource (email thread), and scope (all messages). This distinguishes it from sibling tools like gws.mail.read_message (single message) and gws.mail.search.
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 conveys when to use this tool: when the entire thread content is needed. While it doesn't explicitly name alternatives or exclusions, the 'all messages' wording provides clear context that differentiates it from single-message reads.
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, idempotentHint=false, and openWorldHint=true, covering the mutation and external side-effect profile. The description adds the 'after create_draft' sequencing but does not describe what happens to the draft after sending or other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose and gives a usage hint. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple send action with two parameters and no output schema, the description is adequate. It covers the key prerequisite (create_draft) and the annotation provides the safety context. It could mention irreversibility or external sending, but openWorldHint already signals 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 coverage is 100%, with both account and draftId described in the schema. The description reinforces that draftId comes from create_draft but does not add new meaning beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Send an existing email draft' with a specific verb and resource. It also distinguishes itself from the sibling create_draft by noting 'Use after create_draft', making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use after create_draft' provides explicit sequencing, telling the agent when to use this tool. However, it does not explicitly state when not to use it or name alternative tools, though no direct alternative exists in the 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?
The description adds context about the output (labels and default status) beyond the readOnlyHint and destructiveHint annotations. However, it does not disclose any additional operational behavior such as pagination, sorting, or error conditions. With annotations already establishing the read-only nature, the description adds moderate 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 of 12 words, front-loaded with the verb 'list' and the resource. Every word contributes meaning, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list operation with clear annotations and distinct sibling tools, the description fully covers what the tool does and what it returns. Although there is no output schema, the description explicitly mentions the return content ('labels and default status'), making it complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is fully covered by default. The description appropriately does not attempt to explain parameters; it would have been redundant. This aligns with the baseline for parameterless tools.
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' with a clear resource ('connected Google Workspace accounts') and specifies the returned details ('labels and default status'), clearly distinguishing it from account mutation tools like gws.accounts.add or gws.accounts.remove.
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: you would use this tool when you need to see all connected accounts. However, the description does not explicitly mention when to use it over alternative tools, nor does it provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds specific context by stating that tokens are deleted, which clarifies the exact destructive impact beyond the generic 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 a single, concise sentence that front-loads the core action and outcome. Every word earns its place with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter, full schema coverage, and annotations that already indicate destructive behavior. The description adds the key detail of token deletion, making the total context sufficient for an agent to understand the operation and its consequences.
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% coverage for the sole parameter 'account' with a clear description 'Account label or email to remove'. The description adds no additional parameter semantics, 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 'Disconnect a Google account and delete its tokens' uses a specific verb and resource, clearly distinguishing this from siblings like add, list, reauth, and set_default. It leaves no ambiguity about 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 does not explicitly state when to use this tool or mention alternatives. Usage is implied by the tool name and the action described, but there is no guidance on when to prefer this over e.g. `reauth` or `set_default`.
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 and destructiveHint=false, so the safety profile is covered. The description adds a valuable behavioral detail: that returned content is wrapped in <untrusted-document-content> tags and should not be treated as instructions. This goes beyond annotations and helps prevent prompt injection issues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and the security note is a meaningful addition. No redundant or vague wording is present; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with comprehensive schema coverage and annotations, the description is complete. It states the return fields (title, sheet ID, grid dimensions) and includes a critical security warning. No output schema exists, so the description adequately covers what the agent needs to know.
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 extra meaning to the parameters beyond what the schema already provides. It does mention 'spreadsheet' but not the 'account' parameter, so the schema remains the primary source of parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'List the tabs (sheets) in a Google Spreadsheet with title, sheet ID, and grid dimensions.' This uses a specific verb ('List'), specifies the resource (tabs in a spreadsheet), and distinguishes it from sibling tools like read_range or write_range.
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 by stating what the tool does but does not explicitly explain when to choose this over alternatives or mention any exclusions. Given the sibling context, the purpose is clear enough for an agent to infer, but no explicit guidance is provided.
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 operation read-only and non-destructive, but the description adds substantial behavioral detail: the wrapped <untrusted-document-content> tags, the explicit warning about ignoring instructions inside user data, and the round-trip compatibility with insert_text/replace_text. This goes 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?
Four sentences, each serving a distinct purpose: main function, secondary return, round-trip context, and security warning. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with full schema coverage and no output schema, the description covers return formats (plain text, structured tree), the security-wrapping behavior, and round-trip compatibility. Enough 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for document_id and account. The tool description does not add parameter-specific semantics beyond the schema, so 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 clearly states the tool reads a Google Doc as plain text and mentions the structured Docs tree inclusion. It distinguishes from sibling write tools like insert_text/replace_text by focusing on read behavior, and from drive.read_file by specifying Google Docs.
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 plain text of a Google Doc is needed) but does not explicitly mention alternatives or exclusions relative to siblings like drive.read_file or docs.create. No direct 'use when' 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 state readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds the specific return fields (email, messages total, threads total), which is useful behavioral context beyond annotations. It doesn't overexplain, but this is sufficient for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and contains zero filler. Every word 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a minimal tool with one optional parameter, clear annotations, and a description that lists the exact output fields. No output schema is needed, and the description fully covers what the agent needs to know for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because the only parameter 'account' is fully described ('Account label or email. Uses default if omitted.'). The description adds no additional parameter meaning, 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?
The description uses a specific verb ('Get') and clearly identifies the resource ('Gmail profile info') and the exact data returned (email, messages total, threads total). This fully distinguishes it from sibling mail tools like list_labels or read_message.
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 its usage as a read-only retrieval of account-level profile data, which is distinct from message-level or label-level operations. No explicit alternatives or exclusions are mentioned, but the context is sufficiently clear for an agent to choose this tool for profile information.
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 indicate readOnlyHint=false and destructiveHint=false. The description adds semantic context by mapping label changes to actions like archiving and read/unread status. It does not disclose error scenarios or authorization requirements, but annotations already cover the safety profile, so score 4.
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 19 words, front-loads the core action, includes useful examples, and uses no filler. Highly concise.
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 mutation tool with well-documented schema and no output schema, the description covers common workflows (archiving, starring, read/unread, custom labels). It gives enough context for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema provides 100% coverage for all 4 parameters, each with clear descriptions. The description does not add further parameter-level detail beyond the schema examples, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Add or remove labels from a Gmail message' with a specific verb and resource. It distinguishes from sibling tools like gws.mail.read_message and gws.mail.create_draft by focusing on label modification. Examples of archiving, starring, and marking read/unread clarify the 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?
Provides explicit use cases: 'use for archiving, starring, marking read/unread, or applying custom labels'. This tells when to invoke the tool. Does not specify alternatives or exclusions, but the use cases are clear, earning a 4.
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 valuable context beyond annotations by warning that the tool 'irreversibly modifies user content' and advising user confirmation. It also clarifies literal text insertion (no regex). While destructiveHint is false, this is not a direct contradiction but a caution about 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 action, and every sentence adds value. No fluff or repetition of 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?
The tool is simple and the schema plus annotations cover most details. The description provides essential behavioral context (irreversibility, user confirmation, literal insertion) that completes the picture. No return value is described, but output schema is absent and likely not critical for an insert operation.
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 description coverage, the schema already documents each parameter. The description adds meaning by explaining the 'location' values ('end' or 1-based index) and the literal nature of 'text' (no regex), which goes beyond the schema's simple 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 states a specific action ('Insert literal text into a Google Doc') with a clear scope ('literal', 'No regex'). It distinguishes itself from sibling tools like gws.docs.replace_text by emphasizing literal insertion vs. regex-based replacement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the location parameter ('end' or index) and warns against regex use, implying when to use this tool over replace_text. It also provides a safety guideline ('Confirm intent with the user') for documents not created in the session, but does not explicitly name alternative 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?
Annotations already indicate mutability (readOnlyHint false, openWorldHint true), but the description adds a critical behavioral warning: 'irreversibly modifies user content' and a confirmation requirement. This exceeds the annotation details 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?
Two sentences, front-loaded with the core purpose, then a concise optional behavior and a critical safety warning. No filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with 3 parameters and no output schema, and the description covers purpose, optional behavior, format hint, and a safety warning. It lacks explicit return information, but that is not required given the tool's nature and absence of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, but the description enriches the meaning of initial_values by specifying 'same JSON array-of-arrays shape as write_range', which is not in the schema's basic description. This clarifies expected format beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Create' and resource 'new Google Spreadsheet', clearly distinguishing from sibling tools like write_range or read_range. Also mentions optional seeding, which is a distinct capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use (creating a spreadsheet) and references write_range for shape consistency, offering a subtle alternative. Also warns to confirm intent on documents not created in the session, which is a usage constraint.
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 adds significant behavioral detail beyond annotations: it discloses that the tool opens a browser, returns a pendingId, and requires a follow-up call to complete. It also clarifies that it does not change account label or settings, providing useful boundary information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, then explains the asynchronous flow and non-destructive nature. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the async browser-based flow, the description properly instructs the agent to expect a pendingId and call gws.accounts.complete. It also covers what the tool does not do (changes to label/settings). No output schema exists, but the return value is mentioned.
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 single parameter 'account' is fully described as 'Account label or email to re-authorize.' The tool description repeats this without adding new parameter-level meaning, 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 clearly states the tool's purpose: 'Re-authorize an existing account.' It uses a specific verb and resource, and it distinguishes itself from siblings like gws.accounts.add (new account) and gws.accounts.complete (finalization) by explaining the re-auth flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on usage: opens the browser, returns a pendingId, and explicitly instructs to call gws.accounts.complete to finalize. However, it does not explicitly state when not to use this tool versus alternatives, such as for adding a new account.
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 (destructiveHint=true, readOnlyHint=false), the description discloses that the tool 'irreversibly modifies user content', returns the number of occurrences changed, and clarifies literal substring matching behavior. These details add meaningful context about side effects and output that annotations do not provide. 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 concise and front-loaded, opening with the core operation. Every sentence earns its place: the regex caveat, match_case default, return value, irreversibility, and confirmation warning. No redundant filler or verbose explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters (3 required), destructive annotations, and no output schema, the description adequately covers return value, safety, and key behavioral constraints. It addresses the irreversible nature and the importance of user confirmation, making it sufficient for an AI agent to use safely and 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 input schema already covers 100% of parameters with clear descriptions, including 'literal substring', 'default true' for match_case, and 'may be empty to delete matches'. The description repeats some of this information but does not add new parameter-level semantics beyond what the schema already states. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Replace all occurrences of a literal substring in a Google Doc', giving a specific verb, resource, and scope. It also distinguishes from regex and implies a difference from insertion tools like gws.docs.insert_text, making it highly specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (replacing literal substrings) and includes an explicit exclusion: 'NOT regex'. It also adds a usage caution about confirming intent on documents not created in the session. However, it does not name alternative tools or explicitly say when not to use it beyond the regex caveat, so it stops short of a full 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?
The description goes well beyond the readOnlyHint annotation by detailing the response structure (human-readable preview plus JSON payload), truncation behavior via 'truncated' and 'total_rows_in_range', and the use of <untrusted-document-content> tags with a security warning against prompt injection. This 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 concise and well-structured, with each sentence serving a distinct purpose: purpose, parameter clarification, response format, truncation handling, and security warning. No wasted words, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully explains the return format and edge cases (truncation, untrusted content). All four parameters are documented in the schema, and the description adds the necessary context for effective use. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema covers all parameters (100%), the description adds meaningful context for the 'range' parameter by explaining A1 notation and providing examples. It also implicitly links max_rows to truncation behavior, adding value beyond the schema's bare descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a single range from a Google Spreadsheet, with a specific verb ('Read') and resource ('range'), and distinguishes it from siblings like write_range and list_tabs. It also gives concrete A1 notation examples.
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 reading a range but does not explicitly state when to use this versus alternatives, nor does it mention any exclusions or prerequisites. It relies on the tool name and basic context rather than providing explicit 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 annotations (readOnly=false, openWorld=true), the description reveals key behaviors: it opens the browser, returns a pendingId, and requires polling the complete function. It also notes that each account stores its own credentials, which is a stateful detail not in 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 four sentences, each adding critical information: purpose, OAuth flow with pendingId, credentials storage, and org-specific configuration. No wasted words, and the main verb 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?
The description covers the complete add-account flow, including the async nature, browser interaction, and follow-up poll step. It doesn't mention error cases or timeouts, but given the clear workflow and the schema's parameter descriptions, it is sufficient for an AI agent to invoke it 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?
The schema already documents all three parameters with descriptions, so the baseline is 3. The description adds context for clientId/clientSecret by noting that different organizations need their own credentials from that org's GCP project, which clarifies when these optional parameters matter.
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 function: 'Connect a new Google account via OAuth.' This specific verb+resource combination distinguishes it from siblings like reauth or remove, and the mention of gws.accounts.complete clarifies the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance to call gws.accounts.complete to finalize the pending OAuth flow, and explains that different organizations require their own clientId/clientSecret from their GCP project. However, it doesn't explicitly say when to use reauth instead of add, though 'new account' implies it.
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 (readOnlyHint=false, openWorldHint=true, etc.), the description reveals the non-blocking behavior, the pending status, and the need to poll. This adds valuable context about how the tool actually behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, then the key behavioral note. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description adequately explains the flow, the polling behavior, and the relationship to sibling tools. It is complete enough 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.
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 itself does not add significant parameter details beyond what the schema already provides; it reinforces the purpose of pendingId but adds no new semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finalizes a pending OAuth flow initiated by two specific sibling tools (gws.accounts.add and gws.accounts.reauth). This uses a specific verb and resource, and distinguishes it from the flow-starting 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?
It explicitly references the flow starters and explains the expected calling pattern: returns quickly, may return 'pending', and the caller should call again. This is clear when-to-use guidance with polling behavior described.
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 declaring destructiveHint, the description adds essential context: 'This tool irreversibly modifies user content' and instructs to confirm intent with the user, especially for documents not created in the session. It also explains the behavioral difference between USER_ENTERED and RAW input options.
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 purpose, followed by necessary parameter details and a safety warning. Each sentence contributes meaningful information without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive write tool with no output schema, the description is complete: it covers the core action, parameter semantics for the more complex fields, and includes a clear warning about irreversibility and user confirmation. It equips an agent to use the tool safely and 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%, providing baseline meaning for all parameters. The description adds extra value by detailing the structure of 'values' with an explicit example and clarifying that value_input_option defaults to 'USER_ENTERED'—information not fully present in the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action with a specific verb and resource: 'Write values to a range in a Google Spreadsheet.' It distinguishes from the sibling read tool by the verb 'write' versus 'read,' and the example further clarifies the intended use.
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 that this is for writing values, but it does not explicitly name alternatives like gws.sheets.read_range or specify when-not-to-use. However, it does include a caution to confirm intent with the user, which offers some usage 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:

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

Score Badge

Copy to your README.md:

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

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/orieg/gws-connector'

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