Google Workspace MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools map to a distinct resource and action, and the descriptions clarify boundaries between metadata reads and content reads. The main traps are tasks_lists vs tasks_list, and to a lesser extent drive_export vs docs_get for reading Docs.
Naming Consistency4/5
The set mostly follows a resource_verb_noun pattern, such as gmail_search, drive_create_folder, and calendar_update_event. It loses a point for tasks_lists being a noun phrase instead of a verb action and for inconsistent use of get/read/export across different services.
Tool Count2/5
38 tools is above the 25+ threshold and makes the server heavy for an agent to scan, even though the underlying Google Workspace scope is broad. The two generic workspace_raw/workspace_schema tools add further surface area rather than reducing it.
Completeness4/5
Core workflows exist across Gmail, Drive, Sheets, Docs, Calendar, Tasks, Slides, Forms, and Contacts, with create/read/update coverage for most major objects. Important gaps like Drive upload, non-draft email sending, and task deletion are not directly curated, but workspace_raw/schema can reach those APIs.
Average 3.7/5 across 37 of 38 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 18 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral detail beyond what the annotations already imply. It does not disclose whether completion is reversible, what fields are modified, or what happens to the task after completion. It does not contradict the annotations, but it also does not enrich them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It is concise, though brevity comes at the cost of the semantic depth penalized in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with two required parameters and no output schema, this description is too sparse to be considered complete. It omits parameter format, behavioral effects, and any conditional or edge-case information an agent would need to invoke it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two required string parameters with zero description coverage, and the tool description provides no explanation of what 'task' and 'tasklist' mean, whether they expect IDs or names, or how they relate. The description fails to compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action—'Mark a task done'—with a clear resource and outcome. It is distinguishable from sibling tools like tasks_create and tasks_list, though it does not explicitly name or contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, nor any mention of prerequisites such as the task and tasklist needing to already exist. The intended usage is only implicit from the verb 'mark' and the resource 'task'.
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 and openWorldHint, so the safety profile is covered. The description adds the minimal behavioral trait that all responses for a form are included, suggesting a collection-level read. It does not contradict the annotations, but it also doesn't disclose return shape, pagination, or other runtime behavior.
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 extremely short and front-loaded, with no filler or repeated schema information. It is concise, though it sacrifices clarity by omitting a verb, making it less effective than a similarly short imperative sentence.
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 and minimal parameter documentation, the description should provide more context about what constitutes a response, how responses are returned, or how formId is resolved. The tool is simple, but the description still leaves the agent with too much inference about the actual behavior and return payload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented formId parameter. It only weakly implies that formId identifies the form whose responses are returned; it doesn't explain the expected format, where to obtain the ID, or the required nature of the parameter. This is insufficient compensation for a completely undocumented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource clearly as form responses, and 'Every' hints that this operation returns all responses for a form. However, it lacks an explicit verb like 'list' or 'get', and it does not differentiate itself from siblings such as forms_get or tasks_lists. It is not a tautology, but the intended action must be inferred.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, no mention of prerequisites, and no indication that formId should come from forms_get or another source. The description gives no context for choosing this tool over related read operations 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only safety profile is covered. The description adds that the returned data concerns questions and settings, but it does not disclose any further behavior such as authentication requirements, invalid-formId handling, or response structure. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, front-loaded and contains no filler words, which serves conciseness well. However, the brevity comes at the cost of an explicit verb and operational context, so it is efficient but slightly under-specified.
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 one-parameter, read-only tool, the description conveys the key return scope -- questions and settings -- and annotations cover the safety profile. But with no output schema, the description is the only return-value documentation, and it does not connect the tool to forms_responses or explain how formId should be obtained. This is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description needed to compensate for the undocumented formId parameter, but it never mentions formId directly. The name is self-explanatory enough to suggest which form to fetch, and the phrase 'a form's' hints at that meaning, but that is minimal compensation for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('a form's questions and settings') and implies a read operation, which partially distinguishes it from sibling forms_responses. However, it is a noun phrase with no explicit verb like 'get' or 'retrieve,' leaving the action somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance about when to use this tool versus forms_responses or other read tools. The phrase 'questions and settings' weakly suggests form structure rather than responses, but no alternative tool is named and no when/when-not conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The read-only annotation already covers the safety profile, and the description adds that the result includes body and headers, which is useful beyond the schema. However, the wording 'in full' is slightly misleading because the format parameter can request metadata or minimal representations. No side effects or failure behavior are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-oaded sentence with no filler. It is appropriately short for a simple retrieval tool, though it could have used the space to clarify the format parameter.
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 and 0% parameter descriptions, this tool needs a more complete description to be invoked correctly. An agent would still have to infer the meaning of 'id' and the effects of 'format' from the schema enum alone. The description covers the result type but not enough invocation context for a reliable call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters, but it does not explain that 'id' identifies the message or what 'format' values like full, metadata, and minimal actually return. The only weak hint is 'in full,' which loosely corresponds to the default format value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies that this tool retrieves one specific message and includes the body and headers, so an agent can distinguish it from broader operations like gmail_search or gmail_get_thread. It lacks an explicit verb, though the tool name supplies the action and the meaning is still 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?
No guidance is given about when to choose this tool over siblings such as gmail_get_thread or gmail_search. The description implies a single-message retrieval context but does not state prerequisites, exclusions, or alternatives.
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, so the non-mutating nature is covered. The description adds the return format ('rows as arrays') and a range example, which is useful but does not disclose other behaviors like formatting or formula handling. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and provides a concrete example. Every word contributes value, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema and no schema descriptions, the missing 'spreadsheetId' semantics is a significant gap. The range example is helpful, but the description is not self-sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies the 'range' parameter with an example, but 'spreadsheetId' remains completely unexplained, leaving half of the required parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read') and resource ('cell range') with an example format, making the core operation clear. It does not explicitly distinguish itself from the sibling tool 'sheets_get', so it misses full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as 'sheets_get' or 'sheets_write'. The agent must rely on the tool name and sibling context, with no explicit conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish readOnlyHint=true and openWorldHint=true, covering the operation's safety profile. The description adds that the output is the full conversation in order, which is useful, but it does not disclose details like pagination, response format, or how ordering is determined.
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 very concise and front-loads the core behavior, with usage guidance in the second sentence. Each sentence contributes value, though the first sentence is a noun fragment rather than a complete verb phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool, the description provides good use-case context but misses critical parameter semantics. Without clarifying that 'id' is a thread identifier, an agent cannot reliably invoke the tool, and the absence of an output schema makes the description the only source for understanding return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'id,' has no schema description and the schema description coverage is 0%. The description never explains that 'id' refers to a thread ID or what format it should take, leaving the agent to infer the meaning from the tool name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates that the tool returns 'a whole conversation in order,' which identifies the resource and the result. It also distinguishes itself from fetching individual messages, which differentiates it from gmail_get_message, though it lacks a direct verb like 'retrieves.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to prefer this tool over fetching messages one by one when context is needed, giving a clear usage condition and naming the alternative behavior. It does not specify when the single-message tool should be used instead, so it is not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral detail beyond the annotations by stating that existing cells are replaced, making the overwrite effect explicit. While annotations already indicate a write operation (readOnlyHint=false), the description clarifies the in-place replacement trait. It does not, however, disclose side effects implied by openWorldHint=true or any authorization/format behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler; the core action is front-loaded and the clarifying sentence about replacement is useful. Every word earns its place, and the length is appropriate for a simple mutation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required parameters, no output schema, and zero parameter descriptions, the description is too minimal to be complete. It gives no guidance on range formatting, value dimensions, required spreadsheet context, or when to use this tool versus siblings, so an agent would need to rely on external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden of explaining parameters, but it does not explain the syntax of 'range', the 2D structure of 'values', or the role of 'spreadsheetId'. No parameter detail is provided beyond the names in the schema, leaving agents without sufficient information to construct a correct call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Overwrite') and resource ('a range'), and clarifies that existing cells are replaced, which clearly distinguishes it from read or append operations like sheets_read and sheets_append. However, it does not explicitly differentiate itself from siblings by name, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for overwriting cell ranges but gives no explicit guidance on when to choose it over alternatives such as sheets_append or sheets_get. There is no stated prerequisite, no mention of when not to use it, and the sibling names are not addressed.
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 and openWorldHint, so the safety and world-scope are covered. The description adds that the result is paginated, which is a genuine behavioral fact beyond the annotations. It does not explain how pagination works, what a page contains, or any ordering/rate limits, giving only partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very terse and front-loaded, with no wasted words; 'all' and 'paged' each carry useful information. However, its brevity comes at the cost of leaving out parameter meaning and alternative-tool guidance, so it is economical but not fully appropriate in size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one optional parameter and helpful annotations, the description and schema together are nearly enough to invoke it. Yet the meaning of max, the actual pagination mechanism, and what a page contains remain ambiguous, so the definition is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to explain what max means. It does not: 'paged' only hints at pagination, and max's role as a page size or result limit is left to inference from the parameter name and schemas constraints. This is a notable gap even for a single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (contacts) and makes it clear this is a listing operation with 'All your contacts,' while 'paged' adds a useful behavioral qualifier. It does not explicitly state the verb or contrast itself with contacts_search, but it is clear enough that an agent can tell it returns a broad contact list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'All your contacts' implies this is for retrieving the full/unfiltered list, which loosely contrasts with a search tool. However, the description does not explicitly mention contacts_search or any conditions for when to prefer this tool over alternatives, so usage guidance is only implied.
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 openWorldHint=true, so the description does not need to restate safety. It adds useful context by specifying that the result contains metadata fields including sharing and link, but it does not disclose details like permission requirements, response format details, or pagination, if any. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the operation and resource, then lists the returned metadata fields. There is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 read tool with readOnlyHint and openWorldHint annotations, the description covers the key return fields and makes the tool's purpose understandable. There is no output schema, so the listed metadata fields partially substitute for it, though more detail on the response structure could make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description carries the burden of explaining parameters, but it does not mention fileId at all. The connection between 'one file' and the required fileId is inferable, and the parameter name is self-explanatory, yet the description adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'one file', and specifies the return content as metadata fields such as name, type, size, owners, sharing and link. This distinguishes it from siblings like drive_export, which deals with file content, and drive_search, which lists files. It could be stronger by naming the siblings explicitly, but the differentiation is clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as drive_search or drive_export. The description implies retrieving metadata for a known file, but it does not state exclusions, prerequisites, or the condition that would make a sibling tool 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?
The readOnlyHint and openWorldHint annotations already cover the safety profile. The description adds a useful scope claim that the result includes 'the text on every slide,' but it does not disclose output shape, pagination, or any other runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded phrase with no filler or unnecessary words. Every part contributes to identifying the tool's output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with one parameter, the description gives the core payload. However, it provides no output format, no guidance on when to prefer it, and no elaboration on the openWorld hint, leaving it minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and only a single presentationId string. The description adds the semantic that this ID refers to a presentation via 'A presentation's,' which partially compensates for the schema gap, but it does not explain where the ID comes from or its expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource (a presentation) and the returned content (structure and text on every slide), which is enough to distinguish it from slides_create and other sibling tools. It lacks an explicit verb like 'retrieves' or 'gets', so it does not fully meet the 5 criterion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided, and no alternatives are named. The intended usage is only implied by the tool name and the noun-phrase description, so an agent gets little help deciding between slides_get and related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. But the description adds no behavioral context beyond its scope statement: it does not mention match semantics, output format, result limits, or any caveats about open-world results. With no additional behavioral disclosure, this is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose and query semantics. Extremely concise and well-structured.
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 search tool with one required parameter and annotations covering safety, the description is minimally sufficient. However, it lacks guidance on output shape, when to use vs contacts_list, and the meaning of openWorldHint. These gaps make it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so for the required 'query' parameter by specifying it can match name, email, or company. The 'max' parameter is left to the schema's default/min/max, which are self-explanatory. This meaningful addition for the central parameter earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Search') and resource ('your own contacts') with the searchable fields ('name, email or company'). It is unambiguous about what the tool does, though it does not explicitly differentiate itself from the sibling contacts_list, relying on the word 'search' to imply the distinction.
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: use this tool when you need to find a contact by name, email, or company. However, it provides no explicit guidance about when to choose this over contacts_list, no exclusions, and no mention of using it for listing all contacts. This is implied usage rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds a small amount of behavioral context by stating the result is every task list with its id, but it does not discuss ordering, pagination, fields beyond id, or any additional runtime traits. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse and contains no filler. It is front-loaded and each word earns its place, but it is grammatically a noun phrase rather than a full sentence, which keeps it from being a perfect example of structured conciseness.
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 zero-argument, read-only listing tool with no output schema, the description conveys the core necessary information: all task lists and their ids. It could be more complete by clarifying how this compares to tasks_list or by noting other returned fields, but nothing essential is missing for direct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and schema description coverage is 100%, so the baseline for a 0-param tool applies. No parameter explanation is necessary here.
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 resource is clear: all task lists, each with its id. The plural form of the name and the description distinguish this listing tool from the sibling tasks_list. However, it lacks an explicit verb like 'retrieves' or 'lists', so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool over alternatives, and no sibling such as tasks_list is mentioned. The intended use-case might be inferred from the name and 'Every...', but it is never explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint and openWorldHint, so the safety profile is known. The description adds the RFC3339 format and calendar default, but these largely repeat schema information. It does not disclose behavior such as pagination, result limits, or what happens with an invalid calendarId. No annotation contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler: the core behavior comes first, followed by the needed time format and default calendar. Every clause earns its place, though an explicit verb would make it slightly stronger.
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 read-only listing tool, the description plus schema covers the required time-window call well enough. However, there is no output schema and no mention of return shape, q search behavior, max pagination, or how to target a non-primary calendar beyond the schema default. This leaves moderate ambiguity for more advanced use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60%, so the schema already documents q, timeMin, and timeMax. The description contributes an RFC3339 example and reinforces the primary-calendar default, which is useful but duplicative. It does not add meaning for q or max, though max's min/default/max are present in the schema. Overall this is adequate but not rich.
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 'Events in a window' clearly identifies the resource (events) and the scope (a time window), even though it lacks an explicit verb like 'list'. It is understandable and distinguishable from sibling calendar tools such as calendar_list_calendars, but it does not explicitly name or exclude that sibling, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Events in a window' implies the tool is used to fetch events within a time range, and 'Defaults to the primary calendar' gives a small usage hint. However, the description does not say when to prefer this tool over alternatives like calendar_list_calendars or calendar_search, nor does it provide exclusions or prerequisites.
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 and not destructive. The description adds useful behavioral context by specifying that the presentation is empty and that the tool returns an id. It does not go deeper into authorization or side effects, but for a simple creation tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no wasted words. It leads with the action and resource, then states the return value. Every part of the description 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 creation tool, the description covers the core action and return id. The lack of an output schema is mitigated by stating the return value explicitly. Slight gaps remain around what the title parameter represents and what 'empty presentation' means concretely, but the description is generally sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'title' as a required string, and the description does not clarify its role beyond the obvious presentation title. With 0% schema description coverage, the description should compensate but provides no parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create'), a clear resource ('empty presentation'), and the expected return value ('return its id'). This distinguishes it from siblings like slides_get, docs_create, and sheets_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as docs_create or sheets_create. There is no mention of when not to use it or what conditions would favor a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint, but the description adds a meaningful behavioral detail: completed tasks are hidden unless requested. This is useful because an agent could otherwise assume the returned set is complete, when it is not by default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core purpose is stated first, and the important filtering behavior is placed second. Every word contributes useful 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?
For a read-only list tool with only three parameters, the description captures the essential behavior, and the schema covers requiredness and constraints. However, there is no output schema, no explanation of what the tasklist parameter expects, and no mention of pagination or return shape, leaving some gaps in end-to-end usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters. It only indirectly references showCompleted ('unless you ask for them'), leaving tasklist and max unexplained. The parameter names are somewhat self-explanatory, but the description itself adds minimal semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as tasks contained in a list, which distinguishes it from sibling tools like tasks_lists. It lacks an explicit verb such as 'retrieves' or 'lists', but the tool name plus 'Tasks in a list' make the purpose reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need tasks that belong to a particular list. It also implies that completed tasks require an explicit request via showCompleted. However, it gives no explicit guidance about alternatives or when not to use it, such as referencing tasks_lists for finding list identifiers.
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 and openWorldHint, so the safety profile is covered. The description adds useful context by specifying that the output is structural metadata (names, ids, dimensions), but it does not describe formatting, ordering, or any edge cases such as empty spreadsheets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the tool's output and immediately follows with actionable usage guidance. 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, safe, one-parameter read-only tool, the description is largely complete: it states what is returned and when to use it. The only notable gap is the lack of explanation around the spreadsheetId parameter, which is mitigated by the schema and the parameter's self-evident name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention spreadsheetId at all. The parameter name is self-explanatory, but the description provides no additional guidance on where the ID comes from, its format, or why it is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource and result: spreadsheet structure including every sheet name, id, and dimensions. It differentiates from sheets_read by indicating this is metadata discovery, not a range query, though it lacks an explicit imperative verb in the first phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: read this before a range query so the sheet name is correct. This implies the right moment to use the tool, though it does not name alternative sibling tools or describe when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating operation. The description adds the key behavioral trait that only provided fields are altered, which is important partial-update context beyond what the annotations state. It does not discuss validation or error behavior, but the core transparency is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler, and the primary action is front-loaded. Both sentences provide meaningful information: the operation and the partial-update behavior.
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 seven parameters, no parameter descriptions in the schema, and no output schema, this description is too sparse for fully confident invocation. Important details such as the required eventId, default calendarId, and date-time format are left to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description names no parameters. It does not explain eventId, calendarId's default, or the expected formats for start and end. The description fails to compensate for the lack of schema-level parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific operation: 'Change an existing event.' This distinguishes it from calendar_create_event and calendar_delete_event, and the clause 'Only the fields you pass are altered' adds precise update semantics.
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 gives clear context: use this tool when an existing event should be modified, and pass only the fields that should change. It does not explicitly name alternatives or exclusion cases, so it falls just short of the top score.
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 openWorldHint=true, covering the safety and open-world profile. The description adds query syntax examples and return fields, but does not disclose pagination, result limits, ordering defaults, or how open-world results should be interpreted. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it begins with the core action, gives immediately useful query syntax examples, and states the return fields. There is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 usefully states return fields, and annotations cover the read-only/open-world aspects. However, it does not clarify whether 'q' is optional, how 'max' and 'orderBy' affect results, whether pagination exists, or how this search relates to sibling file tools. It is adequate for straightforward searches but incomplete for edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description must compensate. It effectively explains the 'q' parameter with realistic query examples, but it does not add meaning for 'max' or 'orderBy' beyond what the schema already provides via min/max/default and a brief example. Coverage is uneven.
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 ('Find files'), identifies the resource (Drive files), and names the search mechanism ('Drive query syntax') with concrete examples. This clearly distinguishes it from sibling tools like gmail_search and drive_get_file.
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 through the query-syntax examples, which signal this is for searching files rather than fetching by ID or exporting. However, there is no explicit guidance on when to prefer this tool over drive_get_file, drive_export, or other siblings, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the operation is not read-only and not destructive, so the description does not need to restate that. The description adds a useful behavioral detail: it returns the new spreadsheet's id. It does not disclose side effects beyond creation, but for a simple create tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no filler. Both the action and the result are front-loaded, and every word contributes to understanding the tool's behavior.
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 single-parameter create tool, the description is largely complete: it tells the agent what action to take and what will be returned. The only minor gaps are details like the format of the id or where the spreadsheet is stored, which are not critical for a basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, `title`, with no schema description and 0% coverage. The tool description does not explain what `title` means or how it relates to the new spreadsheet, leaving the agent to rely solely on the property name. This is a clear semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Create a new spreadsheet') and the return value ('return its id'). It clearly distinguishes sheets_create from sibling tools like sheets_read, sheets_write, sheets_append, and sheets_get by signaling the create operation.
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 by the verb 'Create' — an agent can infer this is the tool to use when a new spreadsheet is needed. However, the description gives no explicit when-to-use guidance or exclusions naming alternatives, so it lacks direct comparison with sibling creation 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 a non-read-only, non-destructive operation. The description adds useful behavioral context about the 'due' parameter — that it is RFC3339 and Google ignores the time part — which goes beyond the schema. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core action, and includes the crucial due-date nuance in a single additional sentence. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters and no output schema, the description is too minimal. It does not clarify what 'tasklist' expects (e.g., ID vs name), how 'notes' behave, what the return value is, or how to handle required parameters beyond the schema's structural requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but it only explains 'due' and leaves 'title', 'tasklist', and 'notes' completely undocumented. The provided parameter detail is helpful but insufficient for the other three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource — 'Add a task' — which unambiguously states what the tool does. It differentiates naturally from sibling tools like tasks_list and tasks_complete by the action performed.
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 adding a task) but does not explicitly mention alternatives or exclusions. No guidance is given for when to prefer tasks_complete or tasks_list, though the sibling names make the distinction obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses that sharing is immediately visible to the other person and advises checking the address first. This adds meaningful behavioral context not captured by annotations, though it does not mention permissions or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler. The purpose is stated first, and the cautionary note earns its place by highlighting a real side effect. Wasteless and well-structured.
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 three-parameter tool, the description covers core purpose and a key side effect. However, it omits role semantics, preconditions (e.g. need edit permission on the file), and whether sharing can be revoked or changed. Since no output schema exists, these gaps leave the agent with partial context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only maps 'someone' to email and 'file' to fileId, but provides no explanation of the role parameter, its enum values, or the default. The schema contains the enum/default, so some structure is available, but the description adds little semantic meaning beyond the property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Grant') and resource ('access to a file'), clearly indicating what the tool does. This distinguishes it from other drive tools in the sibling list such as drive_get, drive_export, and drive_trash, none of which perform sharing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the action ('Grant someone access to a file'), but no explicit when-to-use or when-not-to-use guidance is given. No alternative sharing tool appears among siblings, so differentiation is not needed, but the warning about visible sharing is not a usage guideline per se.
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 a meaningful behavioral nuance beyond those flags: the file is recoverable for 30 days and this tool will never perform a permanent delete. This substantially aids an agent's expectations about the operation's irreversibility.
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 the main action front-loaded and the key qualification in the second clause. Every word adds useful meaning; there is no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core trashing behavior is clear, and annotations cover the destructive nature. However, the confirm parameter creates a real ambiguity about whether the action can be undone, and the description does not resolve this. For a simple two-parameter tool this is a notable gap, though the basic call shape remains obvious.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and fileId has no schema description. The tool description does not explain either parameter or mention that confirm=true is required to proceed. Worse, the confirm schema text says 'This cannot be undone,' which appears to conflict with the description's assertion that the file is recoverable for 30 days, leaving an agent confused about the confirmation 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 opens with 'Move a file to the trash,' which names a specific verb, resource, and destination. It further distinguishes the tool from permanent deletion by explicitly stating it is recoverable and deliberately not permanent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for recoverable trashing rather than permanent deletion, but it does not explicitly state when to prefer it over a concrete alternative or when not to use it. The exclusion is generic and not tied to sibling 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?
Discloses a significant non-obvious side effect beyond the annotations: adding attendees imediately sends emails, and advises confirming before calling. Annotations only indicate readOnly=false/destructiv=false and do not capture the external notification behavior, so this adds real 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?
Two short sentences, with the core purpose first and the critical warning second. Every word earns its place and there is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the essential usage and the most important side effect, but with no output schema and no mention of what the tool returns (e.g., an event id needed for later update/delete), the agent is left to infer some post-call behavior. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for attendees by explaining that including them triggers emails. However, schema coverage is only 29% across 7 parameters, and the description compensates for only this one parameter; summary, calendarId, location, and description are largely left to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise action ('Create an event') and the verb 'create' clearly distinguishes it from update/delete/list calendar siblings. It is clear, but adds no scope details (e.g., default calendar or what fields are required beyond the schema), so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tells the agent when to use it (to create an event) and provides an important pre-condition: confirm the attendee list before calling because attendees are imediately emailed. It does not explicitly name alternatives, but no sibling tool duplicates the creation action, so the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate that this is not read-only and not destructive. The description adds the useful behavioral detail that the folder may be created inside another folder, but it does not disclose side effects, permission requirements, or what happens when parentId is omitted.
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 short sentence with no filler. It leads with the core action and appends the only important qualifier, making it easy to scan and immediately actionable.
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 two-parameter create operation this is mostly adequate, and annotations cover the read-only/destructive profile. However, there is no output schema and the description does not state what the tool returns (e.g., the created folder's ID), which an agent may need to chain subsequent calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that parentId is optional and represents a container folder, while name is clearly the folder's name. However, it does not specify the expected value format for parentId or confirm behavior when parentId is absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('create') and resource ('folder'), and the optional placement inside another folder adds scoping that distinguishes it from related sibling tools. The tool name reinforces the resource, and no other sibling creates Drive folders, so confusion is unlikely.
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 communicates the primary use case: creating a folder, with an optional parent folder. It does not explicitly name alternatives or when-not-to-use conditions, but no sibling tool serves the same purpose, so the context is sufficiently clear without exclusions.
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, readOnly=false), the description adds two critical behavioral facts: attendees are notified of cancellation, and the operation is irreversible. This meaningfully supplements the structured metadata and prepares the agent for 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?
Two short sentences, no filler. The core action is front-loaded, and the important side-effect warnings are included efficiently. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive operation, the description covers the key behavioral details, and the confirm parameter is documented in the schema. However, with low parameter coverage and no output schema, the description could have briefly clarified the role of eventId and calendarId. The tool remains callable but not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%: only 'confirm' has a description. The tool description does not compensate by explaining how to specify the event (eventId) or the calendar context (calendarId). While 'delete an event' implies an event identifier, the parameter semantics are largely left to the agent to infer.
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 and resource: 'Delete an event.' This clearly distinguishes it from siblings like calendar_create_event and calendar_update_event, which have different verbs and 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?
Usage is implied: use this tool when an event should be deleted. However, there is no explicit guidance about when to prefer this over calendar_update_event, nor any mention of conditions like event ownership or cancellation workflows. The context is clear but exclusions and alternatives are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations by explicitly guaranteeing that existing content is preserved and that text is appended at the end. This clarifies the non-destructive mutation intent beyond the generic destructiveHint flag.
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 entire description is one compact sentence with no wasted words. It front-loads the core action and adds a valuable caveat about preserving existing 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 append operation with two required string parameters and annotations already indicating this is a non-read, non-destructive write, the description covers the essential behavior. It does not mention return values or confirmation, but given the simplicity this omission is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description does not explicitly describe documentId or text, but the action statement 'Add text... to a Doc' makes the role of text fairly clear, and documentId is inferable from the concept of targeting a Doc. This is bare-minimum compensation for a simple two-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Add text'), a specific target ('Doc'), and a precise behavior ('to the end... without touching what is already there'). This distinguishes it well from siblings like docs_get and docs_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for appending content to an existing Doc, which gives a clear general context. However, it does not explicitly state when to prefer this over docs_create or any other alternative, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the 'Cannot be undone' warning reinforces rather than adds beyond structured data. The description contributes some workflow context—'an agent drafts, a person sends'—but no additional side-effect detail beyond the annotation and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loaded with the key action, then the workflow separation, then the irreversible warning. No filler or repeated detail beyond what is useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter send action, the description and schema together give the agent enough to select and call it: required draftId, confirm flag with warning, and the destructive nature. It does not describe the return value, but no output schema exists and the operation is unambiguously 'send,' so the gap is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers confirm well with default, description, and warning, but draftId has no description in schema. The tool description's 'draft that already exists' supplies minimal semantic context for draftId. With 50% schema description coverage, the description adds only slight 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 and resource: 'Send a draft that already exists.' It also explicitly separates this from creating a draft, which clearly differentiates it from draft-creation tools and removes ambiguous about the operation.
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 gives clear conceptual guidance by stating this tool is for sending an existing draft versus creating one, implying the creation tool should be used for authoring. It does not name a specific sibling tool, but the boundary is explicit enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readonly and non-destructive behavior, but the description adds the critical behavioral detail that the draft is NOT sent and appears in Drafts for a person to review. This is important context that complements the annotations and clarifies the actual side effect.
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 exceptionally concise, with each sentence contributing meaningful information. It front-loads the core action, emphasizes the non-sending behavior, and concludes with the safety rationale, all in three short sentences.
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 draft-creation tool, the description covers the essential behavior and safety profile. It lacks details about output or follow-up workflow with gmail_send_draft, but the required parameters are in the schema and the tool's purpose is sufficiently clear for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, and the description adds no parameter guidance beyond what the schema provides. Only 'to' is documented as 'Comma separated'; cc, bcc, subject, and body receive no additional semantic explanation, leaving the agent to infer expected formats.
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 ('Write') and resource ('a draft'), and immediately distinguishes itself from sending by stating 'It is NOT sent.' This clearly separates it from sibling tools like gmail_send_draft and leaves no ambiguity about what the tool accomplishes.
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 the intended context: creating a draft for human review rather than sending it directly. It frames the tool as 'the safe way to have an agent write email,' which implies when it should be preferred, though it does not explicitly name the alternative gmail_send_draft.
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 the description adds a useful behavioral fact: the returned values are internal ids rather than display names, and they are consumed by gmail_modify_labels. For a simple read-only listing tool with no output schema, this is meaningful context without repeating 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?
This is two short, information-dense sentences. The first states the core result, and the second supplies the critical relationship to a sibling tool and a key gotcha about ids versus display names. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool, the description tells an agent what it returns (labels with ids), why that matters (gmail_modify_labels needs ids), and the id-vs-display-name distinction. It could have specified the exact response envelope or array shape, but the description is adequate for correct invocation and downstream use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%, so the baseline is 4. The description appropriately focuses on return semantics instead of input semantics, since there is no input to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (labels) and the output (each label's id), and it distinguishes the tool from gmail_modify_labels by explaining that label ids are required there. However, it lacks an explicit verb like 'list' or 'retrieve', relying on the tool name to supply the action, which keeps it just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool to obtain label ids needed for gmail_modify_labels, and cautions that ids are not display names. It does not explicitly state when not to use it or name alternatives, but for a zero-parameter list-all tool that guidance is largely unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate that this is a write operation that is not destructive. The description adds the useful nuance that the text parameter becomes the opening body of the document, but it does not disclose return value, location, or other side effects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and resource, then adds the only needed param context. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter creation tool, the input side is fully described and the optionality of body text is clear. The main minor gap is that the returned document ID is not mentioned, which could matter for chaining with docs_append or docs_get, but it is not needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the parameter-documentation burden. It names both params: title as the document title and text as an optional opening body, which adds real meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a new Google Doc.' The word 'new' clearly distinguishes it from docs_append and docs_get, making the tool's purpose unmistakable.
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 clearly establishes that this is the creation entry point among the docs_* tools and indicates the optional input. It does not explicitly mention alternatives or when not to use it, but the name and sibling context make the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld; the description adds a concrete behavioral boundary: it returns message IDs and snippets, not full bodies. This complements rather than contradicts 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?
Two sentences deliver the query syntax, return shape, and sibling routing with no filler. Every phrase contributes and the main behavior is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool, the definition covers query syntax, return shape, and where to get full bodies. The only real gap is not stating that max limits the number of results, though the schema's default/min/max constraints make this a minor issue.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description significantly enriches q by giving usable Gmail operators such as from:, has:attachment, and newer_than:7d. However, schema coverage is 50% and max has no description, so the max parameter's meaning is left mostly to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Search the mailbox' with Gmail's own query syntax. It also distinguishes itself from gmail_get_message by noting it returns only IDs and snippets, so an agent knows the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for when to search and explicitly routes full-body retrieval to gmail_get_message. It does not enumerate exclusions for every sibling, but the main alternative is named.
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 phrase 'without touching what is there' adds useful behavioral nuance: the operation appends rather than overwrites, which complements the annotations (readOnlyHint=false, destructiveHint=false). It provides context beyond the annotations, though it does not describe return values or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and no filler. The usage preference is stated in a second sentence without 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 3-param append tool with annotations present, the purpose and usage are clear. However, the lack of parameter-level guidance and no output schema mean the description is not fully sufficient for correct invocation, especially around range and values formatting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies values are rows and appending happens at the end, but it does not explain spreadsheetId, the A1 range format, or the nested-array structure of values. An agent would need to infer important invocation details from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Add rows to the end of a sheet.' It also distinguishes itself from sheets_write by explicitly positioning sheets_append as the preferred tool for adding data, so an agent can tell them apart.
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?
'Prefer this over sheets_write when adding data' is explicit routing guidance: it names the alternative tool and the condition that selects sheets_append. This gives the agent a clear when-to-use rule without extra inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and openWorldHint=true, and the description does not contradict them. It adds context that the CLI is generated from Google's discovery service, but does not disclose additional behavioral traits such as confirmation requirements, rate limits, or potential impact of destructive calls beyond what annotations and schema already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences; the first front-loads the core selection rule and the second adds breadth and the workspace_schema guide. No wasted words, and the service list is informationally dense.
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 generic high-breadth tool with no output schema, the description gives enough direction to proceed: it defines scope, points to workspace_schema for exact shapes, and the schema covers parameters and delete confirmation. It does not describe return/error behavior, but workspace_schema is positioned to fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all six parameters with descriptions, so the baseline is met. The description's pointer to workspace_schema for exact shape is helpful for path construction, but it does not add parameter-level semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action: call any Google Workspace API method not covered by curated tools. This directly distinguishes it from the many sibling tools, and the list of services makes the resource scope concrete.
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 tells the agent exactly when to use this tool: when curated tools do not cover the needed method. It also directs the agent to call workspace_schema first to learn the request shape, giving a clear usage sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the description aligns with that by saying 'Read' rather than modifying anything. The description adds useful behavioral nuance beyond the annotations: it returns 'full structured content' and implies that the structured output may be heavier than plain text for simple use cases. This enriches the agent's understanding without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with no fluff. The primary action is front-loaded, and the alternative guidance is appended efficiently. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool, the description covers the essential usage and provides a clear alternative. The lack of an output schema is mitigated by the description's mention of 'full structured content,' though a bit more detail about the return shape could make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% because the documentId property has no description. The description does not explicitly explain the parameter, but 'Read a Google Doc's full structured content' implicitly clarifies that documentId refers to the identifier of that Google Doc. This adds some meaning beyond the bare schema, though explicit parameter documentation would be stronger.
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 ('Read') and identifies the exact resource ('a Google Doc's full structured content'). It also contrasts itself with drive_export, making the distinction from a sibling clear and helping an agent select correctly.
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 states when to prefer an alternative: 'For plain prose, drive_export with text/markdown is usually easier to work with.' This provides both a usage condition and a named alternative, leaving no ambiguity about when docs_get is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, so the description does not need to restate mutation. It adds useful behavioral mapping: removing INBOX archives and removing UNREAD marks read. This goes beyond the structured fields 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?
A single action-first sentence with concrete examples, no filler, and no duplication of the schema's structure. Every word contributes to correct use.
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 three-parameter tool with no output schema, the description covers the core behavior, the required message context, and common label idioms. It omits edge-case details such as invalid label handling, but those are not necessary for basic correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by linking add/remove to label operations and by giving concrete label values like INBOX and UNREAD. 'On a message' implies that id is the message identifier, though the description could more explicitly state that add/remove expect label IDs.
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 ('Add or remove labels') and resource ('a message'), then grounds it in concrete Gmail intents (archive, mark read, triage). This clearly distinguishes it from sibling read/search/send tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use this to archive..., mark read..., or triage' explicitly signals when to invoke the tool. It does not enumerate alternatives or exclusion cases, but no close sibling performs label modification, so the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds behavioral context beyond those: the data comes straight from Google's discovery service, and it is meant to inform calls to workspace_raw rather than being executed itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences front-load the core value proposition and then give concrete usage direction. Every sentence earns its place with no filler or repetition.
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 introspection tool with readOnlyHint and openWorldHint, the description is sufficient: it states what is returned and how to use it before workspace_raw. A small gap is that it doesn't describe the response structure, but the discovery-service framing covers most of what an agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents the 'method' parameter with dotted examples. The description adds context about the parameter's purpose, but it does not add new semantic detail beyond what the input schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a schema/metadata lookup: it returns 'the exact parameters and request body a method expects' from Google's discovery service. It distinguishes itself from sibling workspace_raw by positioning itself as the read-before-execute step, so an agent can tell them apart.
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 tells the agent when to use it: 'Read this before workspace_raw rather than guessing field names.' This names the relevant sibling and gives clear temporal ordering, leaving no ambiguity about when this tool is appropriate.
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, so the description doesn't need to restate safety. It adds useful behavioral context: the tool returns all visible calendars (not just owned ones) and that the id field is what matters for downstream operations. This goes beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The first sentence front-loads the core purpose, and the second explains when it is needed. 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 zero-parameter, read-only list tool, the description covers what is returned (all visible calendars and their ids) and why it matters (prerequisite for non-primary work). It doesn't detail every return field, but the id is the critical piece for the stated use case, so the information is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to add about parameters. The baseline for 0 params is 4, and the description appropriately focuses on the return value instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists every calendar visible to the account and returns its id. This is a specific resource (calendars) with a clear action, and it distinguishes itself from sibling tools like calendar_list_events by focusing on calendar metadata rather than events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence provides explicit usage guidance: 'Needed before working on anything other than primary.' This tells an agent when to call this tool before other calendar operations, such as calendar_create_event or calendar_update_event, which would require a valid calendar id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and openWorldHint=true annotations already covering safety, the description adds useful context: it returns actual content rather than metadata and supports Docs, Sheets, and Slides. It does not discuss conversion caveats or output formatting, but the annotations already establish that this is a safe 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?
Two sentences with no filler. The core purpose is front-loaded, and the second sentence quickly routes an agent away from the wrong sibling tool. Every word carries useful signal.
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 2-parameter, read-only export tool with no output schema, the description covers what the tool does, when to use it, and what to pass. The main gap is that mimeType can be application/pdf, which is not fully captured by the 'as text' phrasing, but the schema documentation fills this in.
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 50%: mimeType is described in the schema, but fileId is not. The description compensates by indicating that fileId refers to a Google Doc, Sheet, or Slide. Combined with the schema's mimeType values, agent can understand both parameters well enough to call the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and identifies the resource ('CONTENT of a Google Doc, Sheet or Slide') and the output form ('as text'). It also distinguishes itself from the sibling drive_get_file by noting that the sibling returns metadata only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells an agent when to use this tool ('when you need what is inside') and names the alternative (drive_get_file) that should be used for metadata. This gives clear decision guidance with no need to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![google-workspace-mcp MCP server](https://glama.ai/mcp/servers/navidmoazzez/google-workspace-mcp/badges/card.svg)](https://glama.ai/mcp/servers/navidmoazzez/google-workspace-mcp)

Score Badge

Copy to your README.md:

[![google-workspace-mcp MCP server](https://glama.ai/mcp/servers/navidmoazzez/google-workspace-mcp/badges/score.svg)](https://glama.ai/mcp/servers/navidmoazzez/google-workspace-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/navidmoazzez/google-workspace-mcp'

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