Allows AI assistants to manage multiple Gmail accounts, including searching, reading, drafting, and sending emails with per-account permission controls (full, read-only, or draft-only).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@multiGmailMCP search for emails from Alice in the last week"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that connects your AI assistant to multiple Google accounts simultaneously — Gmail, Calendar, Drive, and Chat — with independent, per-service permission controls (full, read-only, and Gmail's draft-only) for each account.
Since this runs locally, you need your own Google Cloud OAuth credentials:
Go to the Google Cloud Console.
Create a new project (e.g., "Multi-Gmail MCP").
Go to APIs & Services > Library and enable the Gmail API, Google Calendar API, Google Drive API, Google Meet API (needed for adding Meet links / Gemini notes to events), Google Chat API, and People API (needed to resolve Chat participant names/emails).
Go to APIs & Services > OAuth consent screen:
Choose External user type.
Fill in the required fields (App name, User support email, Developer contact email).
Click Save and Continue until you reach the Test users step.
Add the Gmail addresses you plan to connect as test users (required — Google blocks logins for unlisted users).
Click Save and Continue.
Go to APIs & Services > Credentials:
Click Create Credentials > OAuth client ID.
Choose Desktop app as the application type.
Click Create.
Click Download JSON on your new credential.
Rename the downloaded file to credentials.json and place it in the project root.
Related MCP server: Gmail MCP Server
npm install
npm run buildAuthorize each Gmail account you want the server to access. Permissions are set per service — Gmail, Calendar, Drive, and Chat can each be configured independently for a single account.
# Full access to everything (default)
npm run auth
# Shorthand: read-only across all services
npm run auth -- --readonly
# Shorthand: Gmail can draft but not send; Calendar/Drive/Chat are read-only
npm run auth -- --draftonly
# Granular: override individual services
npm run auth -- --gmail=<full|draft|readonly> --calendar=<full|readonly> --drive=<full|readonly> --chat=<full|readonly>Granular flags can combine with the shorthand flags to override just one service, e.g. an account that can never send email but can fully manage your calendar (accept/decline invites, create events):
npm run auth -- --draftonly --calendar=fullThis opens a browser window for Google OAuth. Run the command once per account — credentials are saved locally in tokens.json. Re-running the command for an already-authenticated email replaces its stored permissions.
Note: Your Google Cloud project will be in "Testing" status, so Google shows a "Google hasn't verified this app" warning. Click Advanced then Go to [Your App Name] (unsafe) — this is expected since you built the app yourself.
Re-authenticating existing accounts: If an account was authenticated before Calendar/Drive support existed, before the granular per-service permission model, or before space/membership management was added to Chat, its stored scopes may be missing or narrower than what a tool call needs. Re-run
npm run authwith the flags for the access you want — Google reuses the same consent flow, so no new credentials are needed. Oldtokens.jsonentries (with the previousreadonly/draft_onlybooleans) still work and are read as their closest equivalent (--readonly→ all read-only,--draftonly→ Gmail draft-only with Calendar/Drive/Chat read-only) until you re-auth them.
Add the server to your Claude Desktop configuration file.
Config file location: ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"multi_gmail": {
"command": "node",
"args": ["/absolute/path/to/multiGoogleMCP/build/index.js"],
"env": {
"NODE_PATH": "/absolute/path/to/multiGoogleMCP/node_modules"
}
}
}
}Config file location: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"multi_gmail": {
"command": "node",
"args": ["C:\\absolute\\path\\to\\multiGoogleMCP\\build\\index.js"],
"env": {
"NODE_PATH": "C:\\absolute\\path\\to\\multiGoogleMCP\\node_modules"
}
}
}
}Replace the paths above with the actual absolute path to your project folder.
After editing the config, restart Claude Desktop for changes to take effect.
Create a .vscode/mcp.json file in your workspace (or add to your user settings):
{
"servers": {
"multi_gmail": {
"command": "node",
"args": ["/absolute/path/to/multiGoogleMCP/build/index.js"],
"env": {
"NODE_PATH": "/absolute/path/to/multiGoogleMCP/node_modules"
}
}
}
}On Windows, use backslash paths:
{
"servers": {
"multi_gmail": {
"command": "node",
"args": ["C:\\absolute\\path\\to\\multiGoogleMCP\\build\\index.js"],
"env": {
"NODE_PATH": "C:\\absolute\\path\\to\\multiGoogleMCP\\node_modules"
}
}
}
}VS Code will prompt you to trust the server the first time it starts.
Open the Agent Panel, go to MCP Servers > Manage MCP Servers > Edit configuration to open mcp_config.json, then add:
{
"mcpServers": {
"multi_gmail": {
"command": "node",
"args": ["/absolute/path/to/multiGoogleMCP/build/index.js"],
"env": {
"NODE_PATH": "/absolute/path/to/multiGoogleMCP/node_modules"
}
}
}
}Use absolute paths. On Windows, use backslash paths (e.g.,
C:\\Users\\...).
Add a new MCP server in Cursor settings:
Type: command
Command: node /absolute/path/to/multiGoogleMCP/build/index.js
If you run into module resolution errors, set the NODE_PATH environment variable to <project-path>/node_modules.
Tool | Description |
| List all authenticated accounts |
| Search emails using Gmail search operators |
| Read the full content of an email by ID |
| Read all messages in a thread/conversation |
| Create a draft email (supports cc, bcc, attachments) |
| Send an email (supports cc, bcc, attachments) |
| Reply to an email within its thread (send or draft) |
| Forward an email to new recipients |
| Download an attachment from a message |
| Move an email to trash |
| Permanently delete an email |
| Change an email's read state |
| Star or unstar an email |
| List all labels/folders |
| Apply or remove a label from an email |
| List existing draft emails |
| Send a previously saved draft |
Tool | Description |
| List all calendars in the account |
| List upcoming events, with time range and search filters |
| Get full details of a specific event |
| Create an event (supports attendees, location, all-day, Google Meet, Gemini notes) |
| Update fields on an existing event |
| Delete an event |
| Create an event from natural language text |
| RSVP to an event invitation (accept/decline/tentative) |
calendar_create_event accepts two optional flags:
Flag | Behavior |
| Attaches a Google Meet video conference and returns its join link. |
| Enables Gemini "Take notes for me" auto-generated notes for the Meet space (requires |
Using these requires the Google Meet API to be enabled on your Cloud project (see step 3 above), and the account must be authenticated with calendar=full (the meetings.space.created and meetings.space.settings scopes are bundled into Calendar's full permission tier — re-run npm run auth for accounts authenticated before this was added).
Tool | Description |
| List files/folders in a given folder (or root) |
| Search using Drive query syntax |
| Get metadata for a file or folder |
| Read text content (exports Google Docs/Sheets/Slides as text) |
| Download binary content as base64 (images, PDFs, zips, etc.) |
| Upload a base64-encoded file |
| Create a new folder |
| Move a file or folder to trash |
| Share a file/folder with another user |
| Move a file/folder to a different parent folder |
Tool | Description |
| List Chat spaces/rooms the account belongs to |
| Get details about a single space |
| Create a new named space, optionally with initial members |
| List the members of a space |
| Add or remove a member from a space |
| List recent messages in a space |
| Get the full content of a single message |
| Send a message to a space (optionally as a thread reply) |
| Edit the text of a message you sent |
| Delete a message you sent |
| Add an emoji reaction to a message |
| List or remove reactions on a message |
| Download an attachment from a message as base64 |
| Upload a file and send it as an attachment, with optional text |
Note: The Chat API does not support arbitrary DM creation via user-authenticated OAuth (it requires resolving Chat user IDs through the People/Admin API).
chat_list_spacesalready lists existing DM spaces you can send to.chat_create_spacecreates named spaces (rooms), not 1:1 DMs.
chat_get_attachmentmetadata (resourceName) comes from theattachmentsfield inchat_list_messages/chat_get_messageoutput — the dedicated attachment-metadata endpoint requires app (bot) authentication and isn't usable here.Resolving names: When authenticating as a user (as this MCP does), the Chat API only returns an opaque
users/{id}for message senders, reaction users, and space members — not their name or email.sender/user/memberfields in the tools above are therefore objects ({ name, email }), resolved via a People API lookup on the same numeric ID. Resolution is best-effort: external users or accounts without a visible profile fall back to{ name: "users/{id}" }with no email. This requires the People API to be enabled (see step 3) and thedirectory.readonlyscope, bundled into both Chat permission tiers — re-runnpm run authfor accounts authenticated before this was added.
gmail_search, gmail_list_drafts, drive_list_files, drive_search_files, calendar_list_events, chat_list_spaces, and chat_list_messages accept an optional pageToken parameter and return a nextPageToken field in their JSON response. Pass the returned nextPageToken back in as pageToken to fetch the next page; a null value means there are no more results.
gmail_draft, gmail_send, and gmail_reply accept an optional contentType parameter:
Value | Behavior |
| Plain text email |
| Body is converted from Markdown to HTML |
| Body is sent as raw HTML |
Example — drafting a Markdown email:
{
"email": "you@gmail.com",
"to": "recipient@example.com",
"subject": "Weekly Update",
"body": "# Status Report\n\n**Completed:**\n- Feature A\n- Bug fix B\n\n*Next steps:* Feature C",
"contentType": "markdown"
}The resulting email renders as formatted HTML in Gmail.
Create a new event in a Google Calendar.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account. | ||
| title | Yes | Title/summary of the event. | |
| isAllDay | No | If true, startDateTime and endDateTime are treated as dates (YYYY-MM-DD) for an all-day event. | |
| location | No | Location of the event. | |
| timeZone | No | Timezone for the event (e.g. 'America/Los_Angeles'). Defaults to account timezone. | |
| attendees | No | Comma-separated list of attendee email addresses. | |
| calendarId | Yes | The calendar ID. Use 'primary' for the main calendar. | |
| description | No | Description or notes for the event. | |
| endDateTime | Yes | End date/time in ISO 8601 format. For all-day events use 'YYYY-MM-DD'. | |
| addGoogleMeet | No | If true, attaches a Google Meet video conference to the event and returns its join link. | |
| startDateTime | Yes | Start date/time in ISO 8601 format (e.g. '2024-06-15T10:00:00-07:00'). For all-day events use 'YYYY-MM-DD'. | |
| enableGeminiNotes | No | If true (requires addGoogleMeet), enables Gemini 'Take notes for me' auto-generated notes for the Meet space. Requires a Google Workspace account with Gemini access; silently reported as unavailable otherwise. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits beyond the schema (e.g., what the tool returns, permissions needed, side effects like duplicate events).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 12 parameters and no output schema, the description does not explain what the tool returns, error conditions, or authentication requirements beyond the 'email' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Create a new event in a Google Calendar,' using a specific verb ('Create') and resource ('event in a Google Calendar'). Distinguishes from sibling tools like calendar_update_event and calendar_delete_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like calendar_quick_add or calendar_update_event. Does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a calendar event.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account. | ||
| eventId | Yes | The event ID to delete (from calendar_list_events). | |
| calendarId | Yes | The calendar ID. Use 'primary' for the main calendar. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states 'delete' without indicating whether the action is permanent, requires permissions, or has any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it could be more detailed without sacrificing conciseness. However, it effectively communicates the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and well-defined schema, the description is fairly complete, but it lacks context on behavioral aspects like permanence and permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptions in the schema (100% coverage), so the description adds no additional meaning. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Delete a calendar event', which is a specific verb-resource pair. It distinguishes from sibling tools like calendar_create_event or calendar_update_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool, prerequisites, or when not to use it. For example, it does not mention that the event must exist or that deletion is irreversible.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific calendar event.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account. | ||
| eventId | Yes | The event ID (from calendar_list_events). | |
| calendarId | Yes | The calendar ID. Use 'primary' for the main calendar. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states 'get details of a specific calendar event.' It does not disclose behavioral traits such as authentication needs, rate limits, or what happens on missing data, resulting in minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 7 words, making it extremely concise. It front-loads the verb and resource. However, it is not fully self-contained, which slightly reduces structure quality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should at least mention what details are returned (e.g., 'including start time, end time, title'). It does not, making the description incomplete for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all three parameters have descriptions), so the baseline is 3. The tool description adds no additional information beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'details of a specific calendar event,' making the purpose obvious. It implicitly distinguishes from sibling tools like calendar_list_events (which lists events) but does not explicitly differentiate or mention alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as calendar_list_events. The description lacks any context about prerequisites or scenarios, leaving the agent without selection advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all calendars in a Google account.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states it lists calendars but omits details like permissions, side effects, output format, or rate limits. This is insufficient for an agent to understand the full impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential action without any extraneous information. It is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema, the description is minimally adequate but lacks completeness regarding what is returned (e.g., only IDs or full objects). It does not leverage context to provide a fuller picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter descriptions, so the baseline is 3. The description does not add any additional meaning beyond the schema's definition of the 'email' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'all calendars in a Google account', making the purpose straightforward. However, it does not differentiate from other list tools like calendar_list_events, but the distinction is reasonable due to the resource difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any exclusions or context. The description merely states the action without any situational advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List upcoming events in a calendar.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account. | ||
| query | No | Free text search query to filter events. | |
| timeMax | No | End of time range in ISO 8601 format. | |
| timeMin | No | Start of time range in ISO 8601 format (e.g. '2024-01-01T00:00:00Z'). Defaults to now. | |
| pageToken | No | Pagination token from a previous call's nextPageToken, to fetch the next page of results. | |
| calendarId | Yes | The calendar ID (from calendar_list_calendars). Use 'primary' for the main calendar. | |
| maxResults | No | Maximum number of events to return (default: 10). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose key behaviors like pagination (pageToken), default time range (timeMin defaults to now), or that it returns only upcoming events by default. The term 'upcoming' is ambiguous without defining the time window.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise but at the expense of useful details. For a 7-parameter tool, a slightly longer description would improve usability without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should explain return value structure (e.g., list of event objects). It does not mention pagination, filtering, or the fact that results are limited by maxResults. The description is insufficient given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond saying 'List upcoming events'; it does not clarify parameter usage or relationships (e.g., how timeMin and timeMax define 'upcoming').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List) and the resource (upcoming events in a calendar), which distinguishes it from sibling tools like create or delete events. However, it could be more specific about the scope (e.g., time range) to further differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., calendar_get_event for single events). The description lacks context about when not to use it or what prerequisites are needed (e.g., a valid calendarId).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a calendar event from a natural language string (e.g. 'Lunch with John tomorrow at noon').
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Natural language description of the event. | |
| Yes | The authenticated Google account. | ||
| calendarId | Yes | The calendar ID. Use 'primary' for the main calendar. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions creation but does not disclose side effects, required permissions, or whether events are created immediately. Minimal behavioral context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence with an illustrative example. No wasted words, but could be slightly expanded for clarity on use-case differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple tool with no output schema, description is adequate but lacks details on parsing behavior, error handling, or distinction from 'calendar_create_event'. Complete for basic use but not for nuanced understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for all three parameters. Tool description adds a conceptual example but no extra semantic detail beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a calendar event from a natural language string' with an example. Verb 'Create' and resource 'calendar event' are specific. Distinguishes from sibling 'calendar_create_event' which likely requires structured input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage via natural language but does not explicitly state when to use this over alternatives like 'calendar_create_event'. No when-not-to-use or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
RSVP to a calendar event invitation as the authenticated account (accept, decline, or tentative).
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account (must be an attendee of the event). | ||
| eventId | Yes | The event ID to respond to (from calendar_list_events). | |
| calendarId | Yes | The calendar ID. Use 'primary' for the main calendar. | |
| responseStatus | Yes | The RSVP response to record. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the action is for the authenticated account, but does not mention side effects (e.g., if not an attendee, or if already responded), nor any irreversible consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, perfectly concise with no wasted words. Front-loads the verb and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should hint at return values (e.g., success confirmation or error). It lacks that. Parameter count is manageable, but overall completeness is average for a simple RSVP action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description does not add extra meaning beyond the schema; parameter descriptions in schema are sufficient, but tool description could clarify parameter roles or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (RSVP), resource (calendar event invitation), and scope (authenticated account, responses: accept/decline/tentative). It is distinct from sibling tools like calendar_create_event or calendar_delete_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives, or prerequisites. While it is the only RSVP tool among siblings, the absence of usage context limits clarity for an agent deciding between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing calendar event.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account. | ||
| title | No | New title/summary. | |
| eventId | Yes | The event ID to update (from calendar_list_events). | |
| location | No | New location. | |
| timeZone | No | Timezone for the event. | |
| attendees | No | Comma-separated list of attendee email addresses (replaces existing). | |
| calendarId | Yes | The calendar ID. Use 'primary' for the main calendar. | |
| description | No | New description. | |
| endDateTime | No | New end date/time in ISO 8601 format. | |
| startDateTime | No | New start date/time in ISO 8601 format. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Update' without detailing behavioral aspects such as whether it performs a partial update (only specified fields are changed) or a full replacement. There is no mention of authorization requirements, idempotency, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks important details that could be included without much length. It is front-loaded with the purpose, but every word earns its keep. However, it is too minimal to be highly effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters and no output schema or annotations, the description is insufficient. It does not explain the behavior of the update (e.g., whether start and end times must be provided together, or how attendees are replaced). The agent may need to infer from the schema, which is risky.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description does not add any additional meaning beyond the schema's parameter descriptions. The schema itself is clear, but the tool description offers no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing calendar event' clearly states the action (update) and the resource (calendar event), which distinguishes it from siblings like calendar_create_event and calendar_delete_event. However, it could be more specific by mentioning which fields can be updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., calendar_quick_add for quick additions). It does not specify that the eventId must be obtained from calendar_list_events first, nor does it mention any prerequisites like needing write access to the calendar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a member to a Google Chat space.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account performing the action. | ||
| spaceName | Yes | The space resource name (e.g. 'spaces/XXXXXX'). Get this from chat_list_spaces. | |
| memberEmail | Yes | Email address of the person to add. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as required permissions, whether the user must be a space admin, or side effects like the new member receiving a notification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that efficiently conveys the core action. No unnecessary words, but could be slightly improved by front-loading the resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (3 params, all required, no output schema), the description is minimally adequate. However, it lacks contextual completeness about prerequisites or after-effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and descriptions in schema are clear. The tool description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the resource 'member to a Google Chat space'. It distinguishes from sibling tools like 'chat_remove_member' by specifying the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, or any prerequisites like needing the space name from chat_list_spaces (though hinted in schema).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an emoji reaction to a Google Chat message.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account to react as. | ||
| emoji | Yes | The emoji unicode character to react with (e.g. '👍', '❤️'). | |
| messageName | Yes | The message resource name to react to (e.g. 'spaces/XXXXXX/messages/YYYYYY'), from chat_list_messages name field. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose idempotency, rate limits, authorization requirements beyond the email parameter, or behavior if an identical reaction already exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, short sentence that efficiently conveys the tool's purpose with no wasted words. Front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 required parameters and no output schema, the description is almost complete. It could mention idempotency or membership requirements, but the information is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have descriptions in the schema (100% coverage). The description adds no additional meaning beyond the schema, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('emoji reaction to a Google Chat message'). It distinguishes from sibling tools like chat_remove_reaction and chat_list_reactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., when to remove a reaction instead). No prerequisites or context for usage are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new named Google Chat space (room), optionally inviting initial members.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account to create the space as. | ||
| displayName | Yes | Display name for the new space. | |
| memberEmails | No | Comma-separated list of email addresses to invite as initial members (optional). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It reveals the creation action (a mutation) but omits critical details: required permissions, side effects (e.g., notifications), limits (e.g., uniqueness of displayName), or what happens on duplicate creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no unnecessary words. It perfectly front-loads the action and key features.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with no output schema or nested objects, the description covers the essential operation. However, it lacks information about return values (e.g., the created space ID) and does not address potential errors or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal value beyond schema—only contextualizing memberEmails as 'initial members'. The email and displayName parameters are already well-described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('create'), the resource ('new named Google Chat space'), and optional action ('inviting initial members'). It distinguishes well from siblings like chat_add_member (adds to existing space) and chat_list_spaces (lists existing spaces).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (e.g., for creating a space optionally with members) but provides no explicit guidance on when to use this tool versus alternatives like chat_add_member for adding members later, nor any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a Google Chat message you sent.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account that sent the message. | ||
| messageName | Yes | The message resource name to delete (e.g. 'spaces/XXXXXX/messages/YYYYYY'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only states that the message must be sent by the user, but omits other behaviors like idempotency, error handling, or effects on replies. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no unnecessary words. Every element is meaningful and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with two required parameters and no output schema, the description is mostly complete. It could mention that deletion is irreversible or what happens if the message is not found, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage for both parameters. The description does not add new information about the parameters beyond the schema, but it provides context that the message must be one sent by the user, which indirectly clarifies the 'email' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete', the resource 'Google Chat message', and the scope 'you sent'. This distinguishes it from sibling tools like chat_send_message or chat_update_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., other delete tools) or when not to use it. The description is purely declarative without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download an attachment from a Google Chat message. Use chat_list_messages or chat_get_message first to get the resourceName from the attachments list.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account to use. | ||
| filename | No | The filename of the attachment (from the attachments list, optional but helpful). | |
| resourceName | Yes | The attachment data resourceName from a message's attachments list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read operation but lacks details on return format, error handling, or size limits. Basic intent is clear but missing behavioral specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second provides essential usage context. No extraneous text, front-loaded information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, yet the description does not explain the return format or behavior (e.g., binary data, encoding). For a download tool, this is a notable gap, though the basic workflow is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds little beyond what the schema already provides for each parameter. The mention of 'from the attachments list' echoes the schema description for resourceName.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Download an attachment from a Google Chat message,' using a specific verb and resource. It distinguishes itself from sibling tools like chat_upload_attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use chat_list_messages or chat_get_message first to obtain the resourceName, providing clear when-to-use context and prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full content of a single Google Chat message by its resource name.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account to use. | ||
| messageName | Yes | The message resource name (e.g. 'spaces/XXXXXX/messages/YYYYYY'), from chat_list_messages name field. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read-only operation ('Get the full content'), but it does not detail rate limits, authentication requirements beyond the email parameter, or what constitutes 'full content' (e.g., whether it includes attachments, reactions, or formatting).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose without any redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could be more complete by explaining the return format or fields included in 'full content.' While the description suffices for basic understanding, a more detailed explanation would aid an AI agent in using the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The tool description adds minimal value beyond the schema: it reiterates the email purpose and provides an example for messageName. Baseline of 3 is appropriate as the schema already handles the parameter meaning adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get', the resource 'full content of a single Google Chat message', and the method 'by its resource name'. It effectively distinguishes from sibling tools like chat_list_messages (which lists messages without full content) and chat_send_message (which sends messages).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after listing messages with chat_list_messages to retrieve a specific message's details, but it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details about a single Google Chat space.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account to use. | ||
| spaceName | Yes | The space resource name (e.g. 'spaces/XXXXXX'). Get this from chat_list_spaces. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. While 'get details' implies a read operation, it does not explicitly state read-only nature, error handling, or permissions. The description is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no filler. Every word serves a purpose. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 params, no output schema), the description lacks detail on what 'details' includes, such as space name, type, member count, etc. For an agent, knowing the return structure is important for planning follow-up actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds no additional meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets details about a single Google Chat space, using a specific verb and resource. It distinguishes from siblings like chat_list_spaces (which lists spaces) and chat_get_message (which gets a message), but does not explicitly mention what details are included.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention that chat_list_spaces should be used to list spaces before calling this, or any prerequisites. Missing context for proper selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the members of a Google Chat space.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account to use. | ||
| pageToken | No | Pagination token from a previous call's nextPageToken, to fetch the next page of results. | |
| spaceName | Yes | The space resource name (e.g. 'spaces/XXXXXX'). Get this from chat_list_spaces. | |
| maxResults | No | Maximum number of members to return (default: 50). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only states 'List the members' but fails to disclose pagination behavior, authentication details, rate limits, or error handling. The schema includes a pageToken parameter, but the description does not mention pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, but could benefit from additional context on pagination or return format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and the description does not explain the return format, default sorting, maximum pages, or behavior for invalid space names. The tool has 4 parameters but lacks behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 4 parameters described). The description adds no additional meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List the members of a Google Chat space' using a specific verb and resource, and it effectively distinguishes itself from sibling tools like chat_list_messages and chat_list_spaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like chat_add_member or chat_list_spaces. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent messages in a Google Chat space.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account to use. | ||
| pageToken | No | Pagination token from a previous call's nextPageToken, to fetch the next page of results. | |
| spaceName | Yes | The space resource name (e.g. 'spaces/XXXXXX'). Get this from chat_list_spaces. | |
| maxResults | No | Maximum number of messages to return (default: 25). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'recent' but does not specify ordering, default limit, or pagination behavior. The schema includes pageToken and maxResults, which inform some behavior, but the description itself adds minimal behavioral context. No annotations exist to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no redundancy. Every word serves a purpose, and it is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should ideally indicate what kind of response to expect (e.g., list of message objects). It does not, but the purpose is straightforward. The simplicity of the tool keeps this score from being lower.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema's parameter descriptions. It is consistent but not enriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (messages in a Google Chat space). The word 'recent' adds some context, but it does not differentiate from sibling tools like chat_get_message or chat_list_members, which have distinct purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus alternatives, such as chat_get_message for a single message or chat_list_spaces for space listing. No prerequisites, constraints, or contextual recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List reactions on a Google Chat message.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account to use. | ||
| pageToken | No | Pagination token from a previous call's nextPageToken, to fetch the next page of results. | |
| maxResults | No | Maximum number of reactions to return (default: 25). | |
| messageName | Yes | The message resource name (e.g. 'spaces/XXXXXX/messages/YYYYYY'), from chat_list_messages name field. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral transparency. It only states 'List reactions', but does not disclose pagination behavior, return format, auth requirements, or any side effects. This is insufficient for an agent to understand the tool's behavior beyond the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no extraneous words. It efficiently conveys the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should clarify what the response contains (e.g., list of reaction objects). It does not mention pagination despite having pageToken and maxResults parameters. The description is incomplete for a tool with four parameters and no output schema, leaving the agent guessing about return values and pagination behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented in the input schema. The tool description adds no additional semantic meaning beyond the field names and schema descriptions. A score of 3 is appropriate as the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'reactions on a Google Chat message'. It is concise and directly indicates the tool's function, distinguishing it from sibling tools that add or remove reactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It implicitly suggests usage for listing reactions, but lacks when-not-to-use or prerequisite information (e.g., requiring a messageName). Among siblings, it is the only list tool, so confusion is low, but clarity on pagination and required context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Google Chat spaces (rooms and direct messages) the account belongs to.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account to list spaces for. | ||
| pageToken | No | Pagination token from a previous call's nextPageToken, to fetch the next page of results. | |
| maxResults | No | Maximum number of spaces to return (default: 25). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as pagination, rate limits, or authentication requirements. The presence of pageToken and maxResults in the schema is not explained in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that clearly and efficiently conveys the tool's purpose. It is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with no output schema and three parameters, the description provides the basic purpose but lacks context on pagination behavior, default values, and integration with other tools. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description adds no additional meaning beyond what the schema provides, thus baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'Google Chat spaces' with specific mention of rooms and direct messages. It distinguishes from sibling tools like chat_get_space (single space) and chat_create_space.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing spaces but provides no explicit guidance on when to use this tool versus alternatives like chat_list_members or chat_list_messages. No when-not or prerequisites discussed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a member from a Google Chat space.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account performing the action. | ||
| spaceName | Yes | The space resource name (e.g. 'spaces/XXXXXX'). Get this from chat_list_spaces. | |
| memberEmail | Yes | Email address of the member to remove. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states the action without disclosing behavioral traits like irreversibility, side effects, or role requirements. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, concise sentence that communicates purpose efficiently with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple mutation tool with well-documented parameters, but lacks behavioral context that would help an agent understand implications of use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions. The description adds no extra meaning beyond the action, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (remove) and resource (a member from a Google Chat space). Distinguishes well from siblings like chat_add_member.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While straightforward, no explicit guidance on when to use or prerequisites (e.g., permissions). Context of removing a member is clear from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a reaction from a Google Chat message. Use chat_list_reactions to get the reaction's resource name.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account that created the reaction. | ||
| reactionName | Yes | The reaction resource name to remove (e.g. 'spaces/XXXXXX/messages/YYYYYY/reactions/ZZZZZZ'), from chat_list_reactions name field. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It indicates a destructive action ('Remove') but does not mention authentication requirements, side effects, or what happens if the reaction does not exist. The hint about using list is helpful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence states the purpose, the second provides crucial prerequisite guidance. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers the essential action and input dependency. It could mention the requirement that the email must be the creator of the reaction, but the schema already states that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are described. The description adds value by explaining how to obtain the reactionName via chat_list_reactions, which aids correct invocation. The email parameter is adequately described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove a reaction') and the specific resource ('from a Google Chat message'). It distinguishes from siblings like chat_add_reaction by focusing on removal and referencing chat_list_reactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite ('Use chat_list_reactions to get the reaction's resource name'), guiding the agent on what to do before invoking. It lacks explicit when-not-to-use or alternative tools, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a message to a Google Chat space, optionally as a reply within an existing thread.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The message text to send. | |
| Yes | The authenticated Google account to send from. | ||
| spaceName | Yes | The space resource name (e.g. 'spaces/XXXXXX'). Get this from chat_list_spaces. | |
| threadName | No | Thread resource name to reply within (e.g. 'spaces/XXXXXX/threads/YYYYYY'), from chat_list_messages threadName field. Omit to start a new thread. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility for behavioral disclosure. It only states 'send a message' implying mutation, but lacks details on authorization, rate limits, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and resource, and contains no wasted words. However, it omits important details that could be included without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (3 required), no output schema, and no annotations, the description is too sparse. It does not explain the authentication context or how to obtain required values, leaving the agent to rely solely on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds minimal value beyond echoing the optional reply behavior, which the schema also covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send a message to a Google Chat space' with a specific verb and resource, and mentions optional reply behavior, effectively distinguishing it from sibling tools like chat_add_reaction or chat_delete_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor any conditions or exclusions. The agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit the text of a Google Chat message you sent.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The new text content for the message. | |
| Yes | The authenticated Google account that sent the message. | ||
| messageName | Yes | The message resource name to edit (e.g. 'spaces/XXXXXX/messages/YYYYYY'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral constraint 'you sent', implying you can only edit your own messages. However, without annotations, it lacks other traits like idempotency or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that efficiently states the verb and resource, with no redundancy. It is appropriately front-loaded and concise without being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple edit tool with no output schema, the description is adequate but lacks details on success behavior, error conditions, or whether the message must exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema descriptions cover all three parameters (100% coverage). The description contributes no additional meaning beyond the schema for any parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action 'Edit' and the resource 'text of a Google Chat message', clearly distinguishing from sibling tools like chat_send_message or chat_delete_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., deleting and resending). It does not mention scenarios like correcting typos vs. other updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a file and send it as an attachment to a Google Chat space, with optional accompanying text.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Base64-encoded file content. | |
| text | No | Optional message text to send alongside the attachment. | |
| Yes | The authenticated Google account to send from. | ||
| filename | Yes | The name for the file as it will appear in the message. | |
| mimeType | Yes | MIME type of the file (e.g. 'application/pdf', 'image/png'). | |
| spaceName | Yes | The space resource name (e.g. 'spaces/XXXXXX'). Get this from chat_list_spaces. | |
| threadName | No | Thread resource name to reply within (optional), from chat_list_messages threadName field. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It states upload and send but lacks details on side effects (e.g., visibility, size limits, permissions, or return value). Does not mention that the file is base64-encoded or any restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and resource, no redundancy. Every word is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description does not explain return value or expected response. Given 7 parameters including base64 data and optional thread, more context is needed for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter described. The description adds 'with optional accompanying text' which is already in the schema. Minimal additional value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Upload a file and send it as an attachment to a Google Chat space'. It specifies the resource (Google Chat space) and distinguishes from siblings like chat_send_message (text-only) and chat_get_attachment (retrieve).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when needing to attach a file to a message, but provides no explicit guidance on when to use this vs alternatives (e.g., chat_send_message for text-only, or chat_get_attachment for retrieval). No when-not or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new folder in Google Drive.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the new folder. | |
| Yes | The authenticated Google account. | ||
| parentFolderId | No | ID of the parent folder. Omit for root. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states 'create a new folder' without mentioning side effects, permissions, or error conditions (e.g., duplicate name, invalid parent).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. However, it could incorporate more information without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is too sparse. It omits details about return values, required permissions, and edge cases, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions, which are themselves minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and the resource 'folder' in 'Google Drive', making the purpose unmistakable and distinct from sibling tools that perform other drive operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives, nor any prerequisites or exclusions. The user must infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a file or folder from Google Drive (moves to trash).
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account. | ||
| fileId | Yes | The file or folder ID to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavior of moving to trash rather than permanent deletion, which is important for non-reversible decisions. However, it lacks details on authentication requirements, effects on shared files, or behavior when deleting folders with contents. Without annotations, this is somewhat informative but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and includes the key behavioral note in parentheses. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with well-documented parameters and no output schema, the description adequately covers the action and its trash behavior. It could mention return values or side effects but is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already explains both parameters (email and fileId). The description adds no additional parameter context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (file or folder from Google Drive), and the specific behavior (moves to trash). This is a specific verb+resource that distinguishes it from sibling tools like drive_move_file or drive_search_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, permissions, or scenarios where moving to trash is preferred over permanent deletion or other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a file from Google Drive as base64-encoded binary content. Use for images, PDFs, zips, and other non-text files. Google Docs/Sheets/Slides are exported to a concrete format (default PDF).
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account. | ||
| fileId | Yes | The file ID (from drive_list_files or drive_search_files). | |
| exportMimeType | No | MIME type to export Google-native files (Docs/Sheets/Slides) as (default 'application/pdf'). Ignored for non-Google-native files. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses base64 encoding and default export format but does not mention read-only nature, error handling, or rate limits. Adequate but could be richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences: first defines core action, second adds key details. No fluff, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description mentions base64 content but doesn't specify exact response structure. Covers main use cases but lacks return field names and error scenarios. Adequate for simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with documented properties. Description does not add meaning beyond schema beyond mentioning default export format. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool downloads a file as base64 binary content, specifies file types (images, PDFs, zips) and export behavior for Google native files. Distinguishes from siblings like drive_read_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: 'Use for images, PDFs, zips, and other non-text files' and mentions export for Docs/Sheets/Slides. Implies text files use another tool but doesn't explicitly name alternatives or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata for a specific file or folder in Google Drive.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account. | ||
| fileId | Yes | The file or folder ID (from drive_list_files or drive_search_files). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'Get metadata', implying a read-only, non-destructive operation. However, it does not detail what metadata is returned, authentication requirements beyond the email param, or any side effects. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded. No redundant information. Could be slightly more structured (e.g., 'Returns metadata for a specific file or folder.') but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with two well-documented parameters and no output schema, the description sufficiently covers the tool's purpose and basic usage. The distinction from drive_read_file (content) is clear. Completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for both parameters. The description adds no additional meaning beyond the schema; it does not describe parameters. Baseline 3 is appropriate as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get metadata for a specific file or folder', using a specific verb ('get') and resource ('metadata'). It distinguishes from sibling tools like drive_list_files and drive_search_files by targeting a single file/folder by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies a fileId is needed but does not provide when-not or mention alternative tools. Agents must infer usage from the fileId parameter documentation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files and folders in Google Drive.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account. | ||
| folderId | No | Folder ID to list contents of. Omit or use 'root' for the root folder. | |
| pageToken | No | Pagination token from a previous call's nextPageToken, to fetch the next page of results. | |
| maxResults | No | Maximum number of files to return (default: 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavioral traits. It fails to mention that listing is limited to a single folder (not recursive), pagination behavior, or whether it returns metadata only. The description is too brief to cover necessary behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the purpose. It could be slightly more informative without being verbose, but it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given full schema coverage and no output schema, the description provides minimal context. It does not explain the returned data format or any side effects. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all parameters. The description adds no additional meaning beyond what is in the schema, achieving the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and the resource (files and folders in Google Drive). It distinguishes from sibling tools like drive_search_files, drive_get_file, and drive_create_folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies usage for listing directory contents, but does not differentiate from search or other listing methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a file or folder to a different folder in Google Drive.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account. | ||
| fileId | Yes | The file or folder ID to move. | |
| newParentFolderId | Yes | The ID of the destination folder. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only states 'Move', missing details on permissions, reversibility, or side effects like overwriting or moving to shared drives.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence, no fluff, but lacks structure like bullet points for parameters or usage notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 required params and no output schema, the description is too minimal. It does not inform the agent about potential errors, return values, or whether the operation supports moving to different accounts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no new meaning beyond the parameter names and types already documented. It does not clarify formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action (Move), resource (file or folder), and destination (different folder in Google Drive), clearly distinguishing it from sibling tools like drive_create_folder or drive_delete_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as drive_upload_file or drive_share_file. No prerequisites or context for invocation are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the text content of a file in Google Drive. Works for Google Docs, plain text, and other text-based files.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account. | ||
| fileId | Yes | The file ID (from drive_list_files or drive_search_files). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does not confirm read-only nature, side-effects, or limitations like size or encoding. 'Read the text content' is accurate but minimally informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains what the tool does and supported file types, but could mention that only text-based files are supported and that the output is the text content. Still mostly complete for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds context that fileId comes from drive_list_files or drive_search_files, which aids correct usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'read' and resource 'text content of a file in Google Drive', and specifies supported file types (Google Docs, plain text, other text-based files), effectively distinguishing it from siblings like drive_download_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading text content but lacks explicit when-not or alternative tool suggestions. It differentiates from siblings by mentioning text-based files, but no direct comparison with drive_download_file or drive_get_file.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for files in Google Drive.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The authenticated Google account. | ||
| query | Yes | Search query. Supports Drive query syntax (e.g. "name contains 'report'", "mimeType='application/pdf'"). | |
| pageToken | No | Pagination token from a previous call's nextPageToken, to fetch the next page of results. | |
| maxResults | No | Maximum number of results to return (default: 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It does not mention pagination (despite a pageToken parameter), response structure, rate limits, or authentication requirements. The brief description lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but overly minimal. It front-loads the core action, but every sentence should earn its place; this one does not convey enough detail to be considered efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search tool (4 parameters, no output schema, no annotations), the description is incomplete. It does not explain return values, query capabilities, or edge cases, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The description adds no extra meaning beyond the schema, earning the baseline score. No improvement or degradation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Search' and identifies the resource 'files in Google Drive'. It distinguishes from siblings like 'drive_list_files' (list all files) by implying query-based filtering, but does not explicitly differentiate, which would make it a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'drive_list_files' or 'drive_get_file'. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a file to Google Drive.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Base64-encoded file content. | |
| Yes | The authenticated Google account. | ||
| filename | Yes | The name for the file in Drive. | |
| folderId | No | ID of the parent folder to upload into. Omit for root. | |
| mimeType | Yes | MIME type of the file (e.g. 'text/plain', 'application/pdf', 'image/png'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states 'Upload a file' without detailing mutation behavior (e.g., creates new file, overwrites if exists?), authentication needs (partially covered by email parameter), or side effects. Minimal transparency beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified. It earns its place but could include more useful information without being verbose. Front-loading is effective but content is too sparse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is incomplete. It fails to mention what the tool returns (e.g., file ID, URL), error conditions, or behavior for duplicate filenames. More context is needed for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter context, but the schema already documents each parameter sufficiently. No value added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (upload) and resource (file to Google Drive). It distinguishes from sibling tools like drive_create_folder or drive_read_file, though it does not explicitly mention alternatives. The purpose is clear but lacks explicit differentiation wording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use, or context such as typical file size limits or overwrite behavior. The description is too brief to guide usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply a label to an email. Use gmail_list_labels to get label IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The Gmail address the email belongs to. | ||
| labelId | Yes | The label ID to apply (from gmail_list_labels). | |
| messageId | Yes | The Gmail message ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It only states the action and a prerequisite but fails to disclose behavioral traits such as whether it modifies the message, idempotence, required permissions, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core action, and the second provides a helpful hint. There is no redundancy or waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 required params, no nested objects, no output schema), the description is minimally adequate. However, it lacks behavioral context such as what happens after applying the label or any side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Apply' and resource 'a label to an email', clearly distinguishing it from sibling tools like 'gmail_remove_label' (remove label) and 'gmail_list_labels' (list labels). It also provides a cross-reference to get label IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs users to use 'gmail_list_labels' to obtain label IDs, which is a helpful prerequisite. However, it does not explicitly mention when not to use this tool or provide alternatives for similar actions like removing labels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete an email. This cannot be undone. Use gmail_trash to move to trash instead.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The Gmail address the email belongs to. | ||
| messageId | Yes | The Gmail message ID to permanently delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states that deletion is permanent and irreversible, which is key behavioral information. It could mention potential side effects or permissions, but the core trait is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no unnecessary words. Every sentence provides value: first states action and permanence, second gives alternative usage. Front-loaded with critical info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two required params, no output schema), the description is sufficient. It explains the action and permanent consequence. Could note return value, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions for 'email' and 'messageId'. The description does not add additional parameter meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool permanently deletes an email and distinguishes it from gmail_trash by name. The verb 'delete' and resource 'email' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit alternative (gmail_trash) and implies when to use each (permanent vs move to trash). It could be more explicit about scenarios, but 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.
Draft an email using a specific Gmail account.
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | CC recipients. Multiple addresses can be comma-separated. | |
| to | Yes | Recipient email address. Multiple addresses can be comma-separated. | |
| bcc | No | BCC recipients. Multiple addresses can be comma-separated. | |
| body | Yes | Body content of the email. | |
| Yes | The Gmail address to draft the email from. | ||
| subject | Yes | Subject of the email. | |
| attachments | No | Files to attach to the email. | |
| contentType | No | Content format: 'text' (plain text, default), 'markdown' (converted to HTML), or 'html' (raw HTML). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose that the tool creates a draft without sending, nor any permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence, but could be improved by structuring key behavioral information upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, the description is too minimal. It lacks detail on what the tool returns and its practical effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool drafts an email using a specific Gmail account, but does not differentiate from sibling tools like gmail_send or gmail_reply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as sending immediately or replying to an existing thread.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Forward an email to new recipients. Use gmail_read first to get the original message content.
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | CC recipients, comma-separated. | |
| to | Yes | Recipient email address(es), comma-separated. | |
| bcc | No | BCC recipients, comma-separated. | |
| body | Yes | Body content to prepend before the forwarded message. | |
| Yes | The Gmail address to forward from. | ||
| subject | Yes | Subject of the forwarded email (usually 'Fwd: <original subject>'). | |
| attachments | No | Additional files to attach. | |
| contentType | No | Content format for the prepended body. | |
| originalMessageId | Yes | The Gmail message ID of the email to forward (from gmail_search or gmail_read). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden for behavioral disclosure. It does not disclose important traits such as whether original attachments are forwarded automatically, permissions required, or effect on read status. Only the basic action is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first states the purpose, the second provides a crucial usage hint. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and no output schema, the description is too brief. It does not explain forwarding behavior for attachments, error handling, or the full process. The schema descriptions help but the description should offer more context to compensate for lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that the 'body' is prepended before the forwarded message and that 'subject' is usually 'Fwd: <original subject>', and that 'originalMessageId' comes from gmail_search or gmail_read.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Forward an email to new recipients' which is a specific verb and resource. It distinguishes from sibling tools like gmail_send and gmail_reply by implying this is for forwarding existing emails, and it includes a prerequisite to use gmail_read first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Use gmail_read first to get the original message content', providing clear guidance on the required preceding step. However, it does not mention when not to use this tool or alternatives for replying vs forwarding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download an attachment from a Gmail message. Use gmail_read first to get the attachmentId from the attachments list.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The Gmail address the email belongs to. | ||
| filename | No | The filename of the attachment (from gmail_read attachments list, optional but helpful). | |
| messageId | Yes | The Gmail message ID containing the attachment (id field from gmail_search or gmail_read). | |
| attachmentId | Yes | The attachment ID from the attachments array in gmail_read output. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It implies a read operation ('Download') with no disclosure of auth needs, rate limits, or output format. Behavior is straightforward, but minimal detail beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second gives prerequisite. No unnecessary words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (3 required) and no output schema, description covers essential usage: what it does and how to obtain required IDs. Lacks mention of return format (binary), but that is often assumed for download tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds operational context: email is the account, filename is optional, messageId and attachmentId come from gmail_read output. This enhances meaning beyond parameter descriptions in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Download an attachment from a Gmail message', specifying verb and resource. It distinguishes from siblings by instructing to use gmail_read first to obtain the attachmentId, which is a unique prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Use gmail_read first to get the attachmentId'. This clarifies when to use and prerequisite step. No explicit when-not-to-use or alternatives, but the tool is the only one for this purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Gmail accounts that are currently authenticated and available for use.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full weight. It only states that accounts are listed but does not disclose side effects, authentication needs, or whether accounts are refreshed. For a listing tool, basic behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it could be slightly more informative without increasing length significantly. Still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is adequate for basic understanding. It tells what the tool does, but lacks details about return format or potential errors. For a simple listing, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with 0 parameters, and schema description coverage is 100%. The baseline for 0 params is 4. No parameter information is needed, and the description does not add parameter semantics, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all Gmail accounts that are currently authenticated and available for use.' It is specific and distinguishes this tool from siblings like gmail_send or calendar_list_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or limitations. It simply states the function without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List draft emails in a Gmail account.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The Gmail address to list drafts for. | ||
| pageToken | No | Pagination token from a previous call's nextPageToken, to fetch the next page of results. | |
| maxResults | No | Maximum number of drafts to return (default: 10). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavior. It implies a read-only operation via 'list,' but omits details like response format, pagination behavior, or side effects. The agent lacks crucial information about what the tool returns or how it behaves with invalid inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, non-redundant sentence that efficiently conveys the tool's purpose with no wasted words. It is front-loaded and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description should at least mention the return structure (e.g., list of draft summaries). Without this, the agent cannot fully assess the tool's output, making the description incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds no additional meaning beyond the param descriptions, establishing a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List draft emails in a Gmail account' uses a specific verb ('list') and resource ('draft emails in a Gmail account'), clearly distinguishing it from sibling tools like gmail_send_draft or gmail_delete that have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives (e.g., gmail_search) or prerequisites (e.g., the email must be a valid Gmail address). The description offers no contextual advice for the AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all labels (folders) in a Gmail account.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The Gmail address to list labels for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states the basic action. It does not disclose read-only behavior, required permissions, or any constraints like filter applicability or system labels.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no wasted words, front-loading the key action and resource. Ideal conciseness for a straightforward list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description lacks details on output format, label types (e.g., system vs. user), or any caveats. Without an output schema, more context is needed for correct agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the description repeats the same information ('The Gmail address to list labels for'). No additional meaning is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (labels) with an explicit synonym 'folders', making the tool's purpose unambiguous. It distinguishes itself from sibling Gmail tools that apply, remove, or manage labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as gmail_search or gmail_read. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark an email as read.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The Gmail address the email belongs to. | ||
| messageId | Yes | The Gmail message ID to mark as read. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It only states the action, omitting details like idempotency, effect on labels, or whether it marks the entire thread. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at 6 words, but this brevity sacrifices helpful context. The description front-loads the action but lacks elaboration. It is not verbose, but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 parameters, no output schema), the description is minimally adequate. However, missing behavioral details like error handling or idempotency reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add parameter details. However, it adds no extra meaning beyond the schema, which already describes the parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Mark an email as read) and resource. It is not a tautology, as it clarifies the object. However, it does not differentiate from siblings like gmail_mark_unread or indicate scope (single message vs thread).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., gmail_mark_unread or gmail_read). The description does not mention prerequisites or context, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark an email as unread.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The Gmail address the email belongs to. | ||
| messageId | Yes | The Gmail message ID to mark as unread. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full transparency burden. It only states the action without disclosing side effects, permissions, or state changes beyond the basic operation. Minimal behavioral context is added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description is nearly sufficient. Minor improvements could include noting that the email must be currently read for the action to apply.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds no additional meaning beyond what the input schema provides, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mark an email as unread.' uses a specific verb ('Mark') and resource ('an email') with a clear state change. It distinguishes from siblings like gmail_mark_read or gmail_star/unstar by naming the unread status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Siblings like gmail_mark_read exist but no comparison or prerequisites are mentioned. The usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full content of a specific email by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The Gmail address the email belongs to. | ||
| messageId | Yes | The ID of the message to read. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It only states 'Read the full content' without revealing traits like whether the email is marked as read, authentication requirements, or response format. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with 100% schema coverage and no output schema, the description is adequate but minimal. It does not mention prerequisites (e.g., valid messageId) or any limitations, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (email and messageId) with clear descriptions. The tool description adds 'full content' but does not enhance parameter understanding beyond what the schema already provides. Baseline score of 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'full content of a specific email by ID', distinguishing it from sibling tools like gmail_read_thread (reads a thread) and gmail_get_attachment (gets an attachment).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. The purpose is obvious from context, but the description itself lacks usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read all messages in a Gmail thread/conversation in chronological order.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The Gmail address the thread belongs to. | ||
| threadId | Yes | The thread ID (from gmail_read threadId field or gmail_search threadId field). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions reading in chronological order but omits side effects (e.g., marking as read) and does not clarify if it is read-only. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence (12 words) that is front-loaded and contains no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description does not provide enough context about return format, limitations, or additional behavioral details. It is adequate but incomplete for a read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The tool description adds no extra parameter meaning beyond the schema; baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read'), resource ('Gmail thread/conversation'), and provides distinguishing detail ('in chronological order'). It is specific and distinct from sibling tools like gmail_read or gmail_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies usage for reading a complete thread but lacks guidance on prerequisites or comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a label from an email. Use gmail_list_labels to get label IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The Gmail address the email belongs to. | ||
| labelId | Yes | The label ID to remove (from gmail_list_labels). | |
| messageId | Yes | The Gmail message ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description conveys the core behavior (removing a label) but lacks details on consequences, required permissions, or what happens if the label is not present. It is adequate for a simple mutation but could be richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of two sentences with no unnecessary information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description covers the essential purpose and prerequisite. It is largely complete, though it omits details on success/failure indicators or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all three parameters (100% coverage). The description adds value only by referencing 'gmail_list_labels' for obtaining labelId, which is helpful but does not significantly enhance understanding of email or messageId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: removing a label from an email. It uses a specific verb ('remove') and resource ('label from an email'), and distinguishes itself from sibling tools like 'gmail_apply_label'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs users to use 'gmail_list_labels' to obtain label IDs, providing clear prerequisite guidance. However, it does not include when not to use this tool or alternative approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reply to an email within its existing thread. Use gmail_read to obtain the threadId, messageId (Message-ID header), and references before calling this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | CC recipients. Multiple addresses can be comma-separated. | |
| to | Yes | Recipient email address for the reply. | |
| bcc | No | BCC recipients. Multiple addresses can be comma-separated. | |
| body | Yes | Body content of the reply (plain text). | |
| Yes | The Gmail address to reply from. | ||
| isDraft | No | If true, creates a draft reply instead of sending. Useful for draft-only accounts (default: false). | |
| subject | Yes | Subject of the reply (usually 'Re: <original subject>'). | |
| threadId | Yes | The Gmail thread ID to reply within (from gmail_read Thread-ID). | |
| inReplyTo | Yes | The RFC 2822 Message-ID of the email being replied to (from gmail_read Message-ID). | |
| references | No | Space-separated list of Message-IDs from the References header of the original email (optional). | |
| attachments | No | Files to attach to the reply. | |
| contentType | No | Content format: 'text' (plain text, default), 'markdown' (converted to HTML), or 'html' (raw HTML). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions the need to obtain IDs via gmail_read but does not describe side effects, authentication requirements, or what happens on success/failure. Some additional behavior context would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two efficient sentences. It front-loads the core purpose and immediately provides actionable guidance, earning its length with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters), the description provides essential workflow guidance but omits the return value or output format. Since there is no output schema, the agent lacks information about what the tool returns (e.g., sent message ID or draft ID), leaving the description somewhat incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining how to obtain threadId, inReplyTo, and references from gmail_read, and clarifies the isDraft parameter's usage for draft-only accounts. This extra context enhances semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Reply to an email within its existing thread.' It uses a specific verb (reply) and resource (email thread), and the context of sibling tools like gmail_send and gmail_draft distinguishes it from sending a new message or creating a draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use gmail_read first to obtain threadId, messageId, and references, providing clear prerequisites and usage context. This helps the agent understand when and how to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for emails in a specific Gmail account.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The Gmail address to search within (must be an authenticated account). | ||
| query | Yes | The search query (uses standard Gmail search operators). | |
| pageToken | No | Pagination token from a previous call's nextPageToken, to fetch the next page of results. | |
| maxResults | No | Maximum number of results to return (default: 10). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'Search for emails' with no mention of side effects, authentication specifics, rate limits, or return format. The description does not disclose that it is a read-only operation or explain pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently captures the tool's core functionality without extraneous words. It is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (pagination, query operators, multiple parameters) and lack of output schema, the description is insufficient. It omits details about result format, pagination usage, and limitations. An agent would need more context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the 4 parameters, so baseline is 3. The description adds no value beyond the schema; it does not explain the query syntax or when to use pageToken.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search') and resource ('emails') with a specific scope ('in a specific Gmail account'). It effectively conveys the primary purpose. However, it does not distinguish from sibling tools like gmail_read or gmail_list_drafts, which have similar resource names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., gmail_read for specific messages, gmail_list_drafts for drafts). There are no instructions regarding prerequisites or 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.
Send an email using a specific Gmail account.
| Name | Required | Description | Default |
|---|---|---|---|
| cc | No | CC recipients. Multiple addresses can be comma-separated. | |
| to | Yes | Recipient email address. Multiple addresses can be comma-separated. | |
| bcc | No | BCC recipients. Multiple addresses can be comma-separated. | |
| body | Yes | Body content of the email. | |
| Yes | The Gmail address to send the email from. | ||
| subject | Yes | Subject of the email. | |
| attachments | No | Files to attach to the email. | |
| contentType | No | Content format: 'text' (plain text, default), 'markdown' (converted to HTML), or 'html' (raw HTML). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Send an email' but does not disclose authentication requirements, error handling, or whether it returns a message ID. The description lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence, front-loaded with the action, and contains no waste. However, it could be expanded slightly to include usage hints without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters (4 required), attachments, and a contentType enum, the tool is complex. No output schema is provided, so the description should explain return values (e.g., message ID). It does not. The description is too minimal for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter documented in the input schema. The description itself adds no extra meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Send an email using a specific Gmail account.' It uses a specific verb and resource and distinguishes from sibling tools like gmail_draft (create draft) and gmail_send_draft (send draft).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives such as gmail_reply, gmail_forward, or gmail_draft. The description does not mention context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an existing draft email. Use gmail_list_drafts to get draft IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The Gmail address the draft belongs to. | ||
| draftId | Yes | The draft ID to send (from gmail_list_drafts or gmail_draft). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. The description only states the action without mentioning side effects (e.g., whether the draft is deleted after sending), authorization requirements, or potential constraints. This leaves significant gaps for safe and correct usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the action and provide immediate guidance. No superfluous details, efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers the core action and provides necessary context for obtaining the draft ID. However, it lacks behavioral details (e.g., what happens to the draft after sending) that could be helpful given no output schema or annotations. It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds little additional meaning beyond reinforcing the source of draftId ('from gmail_list_drafts or gmail_draft'). Baseline 3 is appropriate as schema already documents parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send an existing draft email') and the resource ('draft email'). It distinguishes from siblings by referencing gmail_list_drafts for obtaining draft IDs, which helps differentiate from tools like gmail_send and gmail_draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to use gmail_list_drafts to get draft IDs, indicating a prerequisite step. While it implies when to use (sending a draft), it does not explicitly mention when not to use or alternatives like gmail_send for new emails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Star an email.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The Gmail address the email belongs to. | ||
| messageId | Yes | The Gmail message ID to star. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral details such as permission requirements, reversibility, or effects on already starred messages.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with only three words, front-loading the core action. However, it could be slightly expanded for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with full schema coverage and no output schema, the description is minimally sufficient but lacks comparison to sibling tools and behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Star' and resource 'an email', clearly distinguishing from sibling tools like gmail_unstar. It is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs gmail_unstar or other Gmail actions. The description does not indicate prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move an email to the trash.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The Gmail address the email belongs to. | ||
| messageId | Yes | The Gmail message ID to trash (from gmail_search or gmail_read). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. 'Move to trash' implies reversibility, but no details are given about undoing, thread handling, permissions, or rate limits. The description is too brief to cover necessary behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the tool's purpose. Every word is necessary, and there is no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 2 parameters, no output schema, and no annotations. The description fails to explain the return value (e.g., the trashed message or success status) or clarify that the 'email' parameter likely refers to the user's own Gmail address. For a complete context, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by noting that the messageId comes from gmail_search or gmail_read. This context helps the agent understand how to obtain the required ID, going beyond the schema's basic type description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Move an email to the trash' uses a specific verb ('Move') and resource ('email'), clearly indicating the action and destination. It distinguishes from siblings like gmail_delete (permanent deletion) and gmail_star/unstar (labeling), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as gmail_delete (which might be permanent). The description does not specify prerequisites or exclusion criteria, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove the star from an email.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The Gmail address the email belongs to. | ||
| messageId | Yes | The Gmail message ID to unstar. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but lacks important context such as side effects (e.g., idempotency, error behavior if already unstarred), required permissions, or whether any confirmation is needed. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (two parameters, no output schema), the description is adequately complete for basic understanding. However, it could benefit from mentioning what happens if the email is not starred or if there are errors, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with clear descriptions. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the resource ('star from an email'). It effectively distinguishes from sibling tools like gmail_star, which adds a star, and gmail_mark_read, which changes read status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While the purpose is clear enough that an agent can infer it is for removing a star from a previously starred email, there is no mention of when not to use it (e.g., if the email is already unstarred).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0calendar_create_eventcalendar_delete_eventcalendar_get_eventcalendar_list_calendarscalendar_list_eventscalendar_quick_addcalendar_respond_to_eventcalendar_update_eventchat_add_memberchat_add_reactionchat_create_spacechat_delete_messagechat_get_attachmentchat_get_messagechat_get_spacechat_list_memberschat_list_messageschat_list_reactionschat_list_spaceschat_remove_memberchat_remove_reactionchat_send_messagechat_update_messagechat_upload_attachmentdrive_create_folderdrive_delete_filedrive_download_filedrive_get_filedrive_list_filesdrive_move_filedrive_read_filedrive_search_filesdrive_share_filedrive_upload_filegmail_apply_labelgmail_deletegmail_draftgmail_forwardgmail_get_attachmentgmail_list_accountsgmail_list_draftsgmail_list_labelsgmail_mark_readgmail_mark_unreadgmail_readgmail_read_threadgmail_remove_labelgmail_replygmail_searchgmail_sendgmail_send_draftgmail_stargmail_trashgmail_unstarTools are clearly separated by domain-specific prefixes (gmail_, calendar_, chat_, drive_), making each tool's purpose immediately identifiable. Within each domain, operations are distinct, and descriptions provide enough detail to differentiate similar actions like gmail_delete vs gmail_trash or gmail_star vs gmail_unstar.
All tool names follow a consistent 'domain_verb_noun' pattern (e.g., gmail_send, calendar_list_events). While verbs like 'read' and 'get' are used for different actions, they are contextually appropriate and not confusing.
With 54 tools, this server is large but justified by covering four distinct Google services. Some tools like gmail_star/unstar or mark_read/unread could be combined, but the count is still reasonable for a comprehensive multi-service MCP.
The tool set provides extensive coverage for Gmail, Calendar, Chat, and Drive, including CRUD operations, search, attachments, and more. Only minor gaps like drive update file exist, but core workflows are fully supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect any mailbox to Claude, ChatGPT & AI: read, send, reply, schedule & search emails.
Manage Gmail end-to-end: search, read, send, draft, label, and organize threads. Automate workflow…
Give AI agents secure access to your email via private aliases with dedicated mailbox storage.
Email infrastructure for AI agents — send, receive, search, and reply to email over MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/santoshachari/multiGoogleMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
