Gmail Multi-Inbox MCP Server

Server Quality Checklist

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

Latest release: v1.6.2
Disambiguation4/5
Most tools target distinct resources and actions, with clear descriptions differentiating similar ones (e.g., read_emails vs search_emails, get_attachment vs get_all_attachments). Some minor ambiguity exists, such as list_blocked_senders actually listing all filters, but overall boundaries are clear.
Naming Consistency3/5
Tool names generally follow a verb_noun pattern, but conventions vary: some use service prefixes (sheets_create, docs_get), while others are unprefixed (list_accounts, send_email). Singular/plural inconsistency (list_drive_files vs get_drive_file) and mixed styles like 'get_drive_file_content' vs 'sheets_read' reduce predictability.
Tool Count2/5
60 tools is excessive for a server named 'Gmail Multi-Inbox', as it includes Drive, Sheets, Docs, and Calendar. Even as a broader Google Workspace toolkit, the count is heavy and may overwhelm agents, though it does support a wide range of operations.
Completeness4/5
The Gmail surface is thoroughly covered (read, search, threads, labels, drafts, send, attachments, block/unblock, unsubscribe, mute). Other services are also well-covered, with minor gaps like no permanent Drive delete and no Docs delete. Core workflows have no dead ends.
Average 3.7/5 across 60 of 60 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on June 10, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only repeats the tool's name ('Create a new folder') and does not mention permissions, duplicate handling, return values, side effects, or any real behavioral context. For a mutation tool, this is a substantial transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, which is efficient and front-loaded. However, it is somewhat redundant with the tool name and does not include any additional structural elements like examples or context, making it concise but minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations and no output schema, the description should provide more context about behavior, such as what happens if parent_id is omitted or what the response includes. The schema covers the parameters, but the tool's overall behavior remains under-specified, making this less than minimum viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters, so the baseline is 3. The description adds no parameter-specific information, but since the schema already documents name, account, and parent_id meanings, the description need not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' and clearly identifies the resource as 'a new folder in Google Drive,' which unambiguously distinguishes it from sibling tools like create_label or docs_create. It matches the tool name exactly and leaves no doubt about the action performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as upload_drive_file or share_drive_file, nor does it mention any prerequisites like existing parent folders. There is no context about typical use cases or exclusions, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention that sending an email is irreversible, requires authentication, or what happens on success/failure. The description is too sparse 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It is appropriately sized for a tool with a schema that covers parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 8 parameters, no annotations, and no output schema, the description provides minimal context. It omits behavioral details such as the email being sent immediately, attachment handling, or error cases, leaving the description incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 8 parameters are documented in the schema. The description adds no extra meaning beyond reiterating that account is required, which is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends an email, using the specific verb 'send' and resource 'email'. It adds a constraint ('from one account (account required)') but does not explicitly distinguish it from sibling tools like send_draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as send_draft or create_draft. The only hint is that an account is required, which is a parameter constraint rather than usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'create' and gives no information about permissions, idempotency, error conditions, or effects beyond creation. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and to the point. The parenthetical '(account required)' is slightly redundant with the schema, but it does not waste much space. It earns its place by reinforcing a key requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is too sparse. It lacks context about return values, naming constraints, or behavior on duplicate labels. The schema covers params but not operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes all four parameters with names, defaults, and descriptions (100% coverage). The description itself adds no additional parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new Gmail label in a specific account, using a specific verb ('create') and resource ('label'). It distinguishes from sibling tools like delete_label and get_labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives. The 'account required' note is a prerequisite, not a usage recommendation. No mention of get_labels for listing or delete_label for removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'all occurrences' but fails to note that the operation permanently modifies the document, any permission requirements, or what the tool returns. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler words. It front-loads the action and target, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema fully documents parameters, so the core function is adequately described. However, the lack of annotations and output schema leaves out important context such as side effects, reversibility, and return values, making it only marginally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for 100% of parameters, so the baseline is 3. The description adds no parameter-specific details beyond the schema, but does clarify that the replacement applies to all occurrences, which is a slight semantic addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (find and replace) and the target (a Google Doc), specifying the scope as 'all occurrences'. It is distinct from sibling tools like docs_append or docs_apply_style, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus other docs-related tools, nor are any prerequisites or exclusions mentioned. The description only states what it does, not when it should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without revealing side effects, needed permissions, or placement behavior, such as that the chart is added to the specified sheet tab.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that immediately states the purpose, with no filler words. It is appropriately sized for a simple statement, though the tool's complexity might warrant more detail, but that is not a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters, no output schema, and no annotations. The description is too sparse to be operationally complete: it does not clarify expected outcomes (e.g., chart appears on the named sheet), prerequisites, or any side effects. The agent must infer too much behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific meaning beyond the schema; it vaguely references 'data range,' which the schema already documents in the data_range parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'create' and identifies the resource 'a chart in a Google Sheet' and the input 'from a data range.' It clearly distinguishes this tool from sibling tools, none of which mention chart creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It is a bare statement of function with no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It only states that it creates a draft and requires an account, but does not mention that no email is sent, side effects, permissions, or what response to expect. This is minimal disclosure for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action ('Create a draft email') and adds the key constraint ('one account'). There is no filler or repetition beyond the schema, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a moderately complex tool with 11 parameters and no output schema, the description is only one short sentence. It does not explain the draft's behavior (not sent, stored as a draft), threading support, or how it relates to send/list/draft tools. Given the richness of the schema and sibling tools, this is insufficient contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 11 parameters. The description only adds the nuance of 'one account' and that account is required, which is already indicated by the schema's required list. This is a baseline score with no additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'draft email', and narrows scope to 'one account'. This distinguishes it from send/send_draft/list_drafts, though it does not explicitly name sibling alternatives. 'Draft' makes the intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating drafts, not sending them, and the required account parameter is stated. However, it gives no explicit guidance on when to use this versus send_email/send_draft, and does not mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavioral impact. It merely restates the delete action without mentioning irrevocability, permissions, or that attendee notifications are on by default (the send_notifications schema field hints at this but is not referenced).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is maximally concise and front-loaded with the action. No filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is too sparse. It lacks behavioral caveats, expected return behavior, and usage context beyond the deletion verb.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema provides 100% parameter coverage with descriptions for account, calendar_id, event_id, and send_notifications. The description adds no additional parameter semantics, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and identifies the resource as 'a calendar event,' clearly distinguishing it from sibling tools like get_event, list_events, create_event, and update_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool versus alternatives, mention prerequisites, or note when deletion is appropriate. Usage is only implied by the tool's name and the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry transparency. It only states the core action and omits side effects (e.g., where the doc is saved, whether it returns an identifier, or what happens if a title is duplicated). This is a mutation with no behavioral disclosure beyond the act itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It directly communicates the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple create tool, the description lacks essential contextual details: there is no output schema explaining return values, no annotation about safety or side effects, and no note about the destination or requirements. This leaves gaps for the agent in understanding the full impact of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters ('title' and 'account') with clear definitions. The tool description adds no additional parameter semantics, but the schema already suffices, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new Google Doc.' uses a specific verb ('Create') and resource ('Google Doc'), clearly distinguishing from sibling tools like docs_get (reading) and docs_append (modifying). It unambiguously identifies the tool's primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool or how it differs from related creation tools like sheets_create or upload_drive_file. It doesn't mention prerequisites such as account authentication or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It doesn't explain whether formatting replaces or merges with existing formatting, what happens if optional parameters are omitted, or whether write permissions are required. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and lists key capabilities. Every word contributes meaning, and there is no fluff or redundancy. It is both concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, no annotations, no output schema), the description is incomplete. It doesn't mention required parameters, return behavior, or how partial formatting updates are applied. The one-sentence description is insufficient for an agent to fully understand the tool's behavior in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter with examples. The description only lists parameter categories without adding additional meaning, such as how parameters interact or the effect of omitting them. It provides some mild reinforcement but doesn't exceed the schema's value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies formatting to a cell range and enumerates the formatting types (bold, italic, font size, background/text color, alignment, number format, wrap strategy). This distinguishes it from sibling tools like sheets_read or sheets_write, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that this is for formatting only, not for editing values, nor does it reference sibling tools like sheets_write. The intended usage is implied by the tool name and description, but no explicit context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of disclosing side effects, permissions, overwrite behavior, or return values. The single sentence only names the operation without any such details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It is concise and immediately conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should provide more context about behavior, such as required authentication, potential file overwrites, or what is returned. The tool has five parameters but no behavioral info beyond the basic action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover all five parameters (100% coverage), including required account and local_path, and optional name, folder_id, and mime_type. The description adds no extra parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Upload') and the target ('a local file to Google Drive'), which distinguishes it from sibling tools that list, search, read, or modify Drive files but do not upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. Sibling tools exist for other Drive operations, but no comparison is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. For a destructive operation like deletion, it fails to mention that the action is permanent, whether messages are affected, or if special permissions are needed. The description only restates the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler words. It front-loads the core purpose and includes a necessary prerequisite hint ('account required'). It is appropriately sized for a simple delete operation, though it could include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive tool with no output schema or annotations, the description should provide caveats about permanence and clarify the difference from similar tools like remove_labels. The current description is too minimal to fully guide an agent, especially in a context-rich environment with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions (100% coverage) for both parameters (account and label_id). The description adds no additional semantic meaning beyond what the schema states, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Delete a Gmail label') on a specific resource, which differentiates it from sibling tools like create_label or get_labels. The phrase 'in one account' adds scope clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting a label from a single account, but provides no explicit guidance on when to use this tool versus alternatives like remove_labels (which removes labels from messages) or create_label. It mentions 'account required' as a prerequisite, but lacks exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not disclose that applying a style is a mutating operation, whether it overwrites existing formatting, or any error conditions (e.g., invalid indices). The description is minimal and lacks transparent side-effect information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action, target, and method. There is no wasted language or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no output schema, the description alone is adequate but not rich. The schema covers parameters well, but usage context, behavioral expectations, and potential constraints are missing. It is a minimal but functional description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of the parameters, so the baseline is 3. The description adds a small bit of context by mentioning 'character indices' and 'heading or paragraph style', which aligns with the schema, but does not provide any additional parameter-specific meaning beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: applying heading or paragraph styles to a text range in a Google Doc, with a specific method (by character indices). This distinguishes it from sibling tools like docs_append or docs_replace_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing the document to already exist) or exclusions. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get full details', implying read-only, but does not disclose potential errors, required permissions, rate limits, or what 'full details' actually encompasses. For a read operation, the risk is lower, but transparency is still limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It efficiently communicates the core purpose without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three well-documented parameters, but there is no output schema and the description does not explain what 'full details' means in terms of response content. While not critically incomplete, the vague phrase leaves some ambiguity about the returned data, though the low complexity keeps it at a minimum viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all three parameters (account, calendar_id, event_id), giving 100% schema coverage. The description adds no additional semantic meaning beyond what the schema already states, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('full details of a single calendar event'), distinguishing it from sibling tools like list_events (which lists multiple events) and create/update/delete_event. The scope is unambiguous: a single event's complete details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that list_events should be used for multiple events or that create_event is for new events. The description simply states what the tool does without contextualizing its usage among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects. 'Read emails' implies a non-mutating operation, and the description adds the aggregation behavior. However, it does not explicitly state that emails are not marked as read, mention required permissions, or describe the return format, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that effectively communicates the core purpose and the key account behavior. It is front-loaded with the verb and resource, and every word earns its place with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the essential purpose and account aggregation behavior, which is adequate for a simple read tool. However, it lacks sibling differentiation (especially from 'search_emails'), does not mention the query parameter or return structure, and has no annotations or output schema to fall back on, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all 4 parameters (100% coverage), so the baseline is 3. The description's mention of omitting the account overlaps with the schema's description of the account parameter, adding no new semantic value. It does not compensate for any gaps beyond what the schema already covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Read' with the resource 'emails' and clearly states the scope: one account or aggregated across all enabled accounts. It is clear in its purpose, but it does not explicitly differentiate from the sibling tool 'search_emails', which might overlap in function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_emails' or 'get_email_thread'. It only explains the account omission behavior, not the appropriate context for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only says 'rename', implying a mutation, but does not disclose potential side effects, error conditions, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero redundant information. It efficiently states the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description is clear, but it lacks any mention of side effects, uniqueness constraints, or error behavior. Given the absence of annotations and output schema, a bit more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds no additional meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'rename' with a clear resource 'sheet tab' and location 'spreadsheet'. It clearly distinguishes from sibling tools like sheets_add_tab and sheets_delete_tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states the action without mentioning scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects. It identifies the action as moving messages to trash, but does not explain consequences (e.g., whether messages are recoverable, if it affects threads, or permission requirements). Minimal behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and scope. It contains no unnecessary words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with two required parameters and no output schema, the description is minimal. It lacks context on return value, permission needs, or reversibility, but the action is straightforward. More detail would improve completeness, especially given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of parameters with descriptions for 'account' and 'message_ids'. The description adds no additional semantic meaning beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Move' with resource 'messages' and scopes it to 'one account', clearly distinguishing it from siblings like trash_drive_file and archive_emails. It unambiguously states the tool's action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over alternatives such as archive_emails or trash_drive_file. It only notes that an account is required, which is a prerequisite, not usage context. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 does not mention side effects like whether moving via add_parents also needs remove_parents, whether updates are reversible, or if special permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently communicates the tool's function. No fluff or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a straightforward update tool with a fully-described schema, but it omits potential interaction details (e.g., behavior when both add_parents and remove_parents are provided) and does not mention output or side effects. Given the complexity of 7 parameters, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description groups parameters into operations (rename, move, star, description), adding light semantics, but does not reveal additional nuance beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a Drive file and enumerates specific operations (rename, move, star/unstar, description). This distinguishes it from siblings like upload, get, or trash, which have different verbs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives like get_drive_file or share_drive_file. The description implies its use case but does not state exclusions or prerequisites beyond the schema's required fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Add labels to messages,' which implies modification but fails to disclose key behaviors such as whether labels are appended or replaced, idempotency, or side effects. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the action and the key prerequisite. It contains no filler or redundancy, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with straightforward parameters, the description is functional but incomplete. It does not explain label replacement semantics or outcome expectations, which an agent would need for accurate prediction. Without annotations, this is a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of parameters, so the baseline is 3. The description adds only the 'one account' scoping detail, which is minor and does not significantly enrich understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and resource ('labels to messages'), and further clarifies scope ('one account'). This clearly distinguishes it from sibling tools like remove_labels and create_label, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its action-oriented wording and adds a prerequisite ('account required'), but it does not explicitly state when to use this tool versus alternatives or provide exclusions. This is adequate but minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only states that it starts onboarding and accepts credentials formats, but gives no details on side effects, return values, interactive steps, or failure modes. This is a significant gap for an auth tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and includes the key input detail. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, no annotations, and no output schema, the description should explain the OAuth lifecycle, any prerequisites, and how this relates to finish_account_auth. It only gives a minimal overview, which is inadequate for an unfamiliar agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all five parameters. The description adds that credentials can be provided as JSON or path, but this largely duplicates the schema fields. It doesn't clarify precedence or whether any parameter is conditionally required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Start OAuth onboarding for an account' with a specific verb and resource. Accepting credentials JSON or a path adds detail. The name contrasts with the sibling finish_account_auth, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the entry point for OAuth authentication by saying 'Start OAuth onboarding,' but it doesn't provide explicit when-to-use instructions or mention alternatives like finish_account_auth. The context is somewhat clear but no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the single-account constraint and account requirement, but does not disclose effects on message state, error handling, return values, or idempotency. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded with the action. It contains no filler or redundant information, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool mutates messages and lacks both annotations and an output schema, the description should provide more context about the operation's effects and expected outcome. It covers the account constraint but leaves out crucial details like return behavior or what happens after marking messages as read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds only 'account required', which reinforces the required field but adds no extra meaning for message_ids. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool marks messages as read, uses a specific verb ('Mark'), and specifies the resource ('messages as read'). It also adds scope ('in one account') and a prerequisite ('account required'), which distinguishes it from sibling tools like archive_emails or read_emails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'account required' and 'in one account' provide usage context by indicating a prerequisite and a limitation. However, it does not explicitly mention when to use this tool versus alternatives, nor does it provide exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the fact that it adds a tab. It fails to mention that this is a write/mutation operation, any permission requirements, error behavior, or side effects on existing data. The verb 'add' implies mutation, but the description lacks the contextual detail needed for safe autonomous use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of eight words, making it extremely concise and front-loaded. Every word contributes to the core message without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters, no output schema, and no annotations. While the description states the core purpose, it lacks any guidance on behavior, such as what happens with a duplicate title or an out-of-range index, and does not provide any usage context beyond the single sentence. For a mutation tool with no structured metadata, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for each parameter (account, spreadsheet_id, title, and optional index). The description adds no additional meaning beyond what the schema already provides, so it earns the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Add' with a clear resource 'new sheet tab' and modifies it with 'to an existing spreadsheet,' which distinguishes it from sibling tools like sheets_create (creating a new spreadsheet) and sheets_rename_tab/delete_tab (modifying existing tabs). This makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for adding to an existing spreadsheet, which sets it apart from sheets_create, but it does not explicitly say when to use it versus alternatives or provide any exclusions. There is no mention of prerequisites or conditions, so the guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. While 'Delete' implies a destructive operation, it does not disclose that deletion is likely permanent, that it shifts indices of remaining rows/columns, or any other side effects. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that wastes no words. It is appropriately front-loaded with the action and target resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is too sparse. It fails to mention irreversible consequences, how indices are affected, or any operational context. The schema provides parameter details but not higher-level behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters already documented (e.g., start_index as zero-based, dimension as ROWS/COLUMNS). The tool description adds no additional parameter semantics, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('rows or columns from a sheet'), and the tool name reinforces this. It distinguishes from sibling tools like sheets_insert_dimension and sheets_delete_tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (whenever rows or columns need to be removed from a sheet), but it does not provide explicit guidance on when to prefer this over alternatives, nor does it mention 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.
Behavior2/5
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 does not mention that deletion is destructive or irreversible, nor any permissions or side effects. The description merely repeats the verb 'delete' without adding context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and contains no wasted words. It is appropriately sized for a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with fully described parameters, the description is minimally sufficient but lacks behavioral context such as irreversibility or error conditions. It is not misleading but does not fully elaborate on the operational impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all three parameters, so the description adds no additional parameter-specific meaning. The baseline of 3 is appropriate since the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Delete a sheet tab from a spreadsheet' with a specific verb and resource. It distinguishes itself from sibling tools like sheets_add_tab and sheets_rename_tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to delete a sheet tab) but provides no explicit guidance on when to use this tool versus alternatives, nor 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose side effects such as shifting existing data or that inserted rows/columns are blank. It only states the basic action without any impact details, requiring the agent to infer consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 13 words conveys the core purpose with no redundant information. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations and no output schema. The description does not mention return values, effects on existing data, or prerequisites, leaving the agent without a complete picture for such a multi-parameter operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for all six parameters, so the baseline is 3. The description does not add additional parameter semantics beyond referencing 'rows or columns' and 'specified position', which map to dimension and start_index.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (insert), the target (rows or columns), and the location (specified position). It distinguishes from sibling tools like sheets_delete_dimension and sheets_append by focusing specifically on inserting dimensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inserting structure at a specific position but does not explicitly state when to prefer this over alternatives like sheets_append or sheets_write. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action without disclosing behavioral details such as reversibility (trash can be restored), required permissions, or idempotency. With no annotations available, the description carries the full burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundancy; it efficiently conveys the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool, the description is sufficient to understand the action, though it lacks behavioral caveats. The schema fully documents the parameters, making it adequate for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (account, file_id) have clear descriptions in the schema, so the description does not need to add extra semantics. The baseline of 3 is appropriate given the 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Move') with a clear resource ('Google Drive file') and destination ('trash'), clearly distinguishing it from sibling tools like update_drive_file or share_drive_file. It unambiguously states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are any exclusions or prerequisites mentioned. The usage is only implied by the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose the core mechanism (creating a filter) and the optional existing-mail trash behavior, but it omits important side effects such as the filter persisting after the call, the fact that the filter action is configurable (trash/archive/spam), and how to reverse the block (unblock_sender sibling exists but is not mentioned). A user cannot infer reversibility or what happens to incoming mail beyond 'block'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the primary action and mechanism, then a concise optional behavior. Every word earns its place; there is no fluff, repetition, or unnecessary detail. This is an exemplary concise description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description only partially covers the needed context. It explains the mechanism and optional existing-mail trash, but it does not mention how to undo the block, when to prefer this over trash_emails, or that the filter action can be archive/spam. The schema covers parameters well, but the broader behavioral context is incomplete for a mutating tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are fully described in the schema (account, sender, action, also_trash_existing). The description adds only a high-level context that the filter mirrors Gmail's Block button, which does not meaningfully elaborate on individual parameters. It provides no additional syntax or format details beyond what the schema already documents, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Block a sender' and identifies the resource (sender) plus the mechanism ('by creating a Gmail filter'). It clearly distinguishes this from sibling tools like trash_emails (which only trashes selected messages) and unblock_sender (which removes a block). The reference to Gmail's native Block button makes the purpose instantly recognizable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by equating the action to Gmail's Block button, but it does not explicitly state when to use this tool versus alternatives such as trash_emails or archive_emails. There are no exclusionary statements (e.g., 'use this when you want to prevent future mail; use trash_emails for one-off deletion'). The optional trash behavior is mentioned, but no alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the primary behavior (retrieving full text and title) and implies a read-only operation, but does not mention permissions, error behavior, return format, or whether formatting is preserved. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core function and contains no redundant information. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains the return value at a high level but omits specifics such as return structure, potential errors, or authentication requirements. It also lacks guidance for choosing this tool over sibling read tools, making it minimally adequate rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers 100% of parameters with descriptions for 'account' and 'document_id'. The description adds no extra parameter-level meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('Google Doc'), and specifies the exact return content ('full text content and title'). This distinguishes it from sibling tools like docs_append or get_drive_file_content by focusing on reading Google Doc text and title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_drive_file_content or docs_* editing tools. No use cases, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It does not state that the operation is read-only, what the response format is, or any prerequisites beyond 'enabled accounts'. The description is too thin to convey meaningful non-obvious behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no fluff. It is front-loaded with the action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional param, no output schema), so the description is adequate to convey its basic function. However, it does not mention what the returned list contains (e.g., calendar names, IDs), which could matter for chaining calls. Given the lack of output schema, a bit more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional parameter, so the baseline is 3. The description repeats the parameter's purpose ('one or all enabled accounts') but adds no new semantic detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), names the resource ('Google Calendars'), and clarifies the scope ('for one or all enabled accounts'). This clearly differentiates it from sibling tools like list_accounts or list_drive_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating you can list calendars for one or all accounts, but it doesn't explicitly mention when to use it (e.g., before get_event) or provide alternative tool guidance. Context is minimal but clearly not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely says 'Create' without mentioning required permissions, whether the operation is idempotent, what the return value is, or any side effects. This lack of detail is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the core purpose without any fluff or repetition. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two documented parameters, but there is no output schema and no annotations. The description does not mention the return value (e.g., spreadsheet ID or object), which an agent would need to know to use the result. It is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes both parameters (title and account) with clear descriptions, achieving 100% schema coverage. The description adds no further semantic meaning about parameter formats, constraints, or relationships, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a new Google Sheets spreadsheet'). It distinguishes from sibling tools like sheets_get, sheets_read, and sheets_write, which operate on existing spreadsheets, and from sheets_add_tab, which adds tabs within a spreadsheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a new spreadsheet, but it does not explicitly state when to use it versus alternatives or provide any exclusions or context about prerequisites. No guidance on when not to use it is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states a simple listing action and that an account is required, without disclosing authentication needs, ordering, system label inclusion, or error behavior. The requirement is a prerequisite, but other 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the core action and scope, with no filler or repetition. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, no output schema, and no annotations. The description gives the essential scope and a key prerequisite, which is largely sufficient for a listing tool. However, it omits any detail on return format or behavior, though the low complexity reduces the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already describes 'account' as 'Account id.' The description's '(account required)' is redundant with the required array. No additional meaning beyond the schema is provided, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List labels' with a verb and resource, scoped to 'one account'. This distinguishes it from label-mutating siblings like add_labels, remove_labels, create_label, and delete_label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'account required' implies a prerequisite but provides no explicit guidance on when to use this tool versus alternatives. Context suggests it is for listing labels within a specific account, but no exclusions or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It says 'adding a permission' but does not disclose side effects like whether this overrides existing permissions, potential public exposure with type=anyone, auth requirements, or that send_notification is controlled by a parameter. The tool is mutating and this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is immediately informative. Every word earns its place, and there's no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, 4 required, no output schema, and no annotations, the description needs to convey more context: what happens when sharing, how to handle role/type combinations, and whether a response is returned. The description is too sparse for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema provides descriptions for all parameters. The description adds little beyond the phrase 'adding a permission,' which doesn't explain parameter combinations like role/type or email requirements. Baseline of 3 is appropriate since the schema handles documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Share a Google Drive file by adding a permission.' This uses a specific verb ('share') and resource ('Google Drive file'), and distinguishes it from sibling tools like trash_drive_file or upload_drive_file, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to share a file, and the sibling list suggests alternatives for other file operations. However, it does not explicitly state when not to use this tool (e.g., for updating permissions, use update_drive_file) or provide alternative tool names. It gives clear context though.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It implies a read-only operation but does not mention response format, error handling, authentication needs, or any side effects. The only extra detail is that 'A1:D10' refers to the first sheet, which is more parameter semantics than behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the tool's purpose, includes helpful examples, and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only four parameters, and the schema covers all of them. The description clearly explains the core action and range notation. However, it lacks any mention of return values or usage context, but given the simplicity and richness of the schema, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all parameters with 100% coverage, so baseline is 3. The description adds extra meaning for the 'range' parameter by explicitly stating that 'A1:D10' targets the first sheet, which is not fully explicit in the schema's example. This provides value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool reads cell values from a Google Sheet range, with a specific verb ('Read') and resource ('cell values from a Google Sheet range'). It also provides concrete examples of range notation, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like sheets_write or sheets_append, nor does it mention any exclusions or prerequisites. It simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that text is appended to the end and that heading/bold/italic can be applied, but it doesn't mention any side effects (e.g., formatting resets, cursor position, or whether existing content is preserved). It doesn't state if the operation is idempotent or if it requires specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that states the core action and optional formatting. No wasted words, front-loaded with the primary verb and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (append with optional formatting), and the schema covers all parameters. However, there is no output schema and no annotations, so the description could usefully mention return value (e.g., updated document ID) or error conditions. The description is complete for basic usage but lacks details like whether appending creates a new paragraph or handles empty docs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by framing the parameters (e.g., 'heading style' for style) but doesn't provide additional detail beyond the schema, such as default behavior when style is omitted or how bold/italic interact with existing formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('append') and resource ('Google Doc'), clearly indicating the action. It also distinguishes from siblings like docs_replace_text and docs_insert_table by focusing on appending to the end, and includes optional formatting details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (appending text to a doc) but does not explicitly state when to choose this over docs_replace_text or docs_apply_style. It doesn't mention prerequisites like document access or that the document must exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the full burden of behavioral disclosure. It states the basic removal action but does not mention side effects (e.g., permanent deletion), error behavior when no filter matches, or what happens if multiple filters match the sender. This is insufficient for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of two sentences that state the action and parameter selection. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and parameter semantics, but given the absence of annotations and output schema, it falls short of full completeness. It does not describe failure modes, idempotency, or how the tool relates to block_sender, leaving some gaps for a simple but mutating tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the schema by explaining the difference between filter_id ('exact match') and sender ('matches filters whose from criteria equals this value'). It clarifies when each parameter is appropriate, complementing the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Remove a Gmail filter') and the resource it operates on. It distinguishes itself from siblings like block_sender and list_blocked_senders by the inverse relationship implied by the name and the specific filter-matching criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on parameter selection ('Specify either filter_id or sender') but does not explicitly state when to use this tool over alternatives. The usage context is implied by the name and sibling tools, not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and does reveal the key behavior: it archives by removing the INBOX label. However, it does not disclose other behavioral details such as reversibility, permissions, or whether messages remain accessible elsewhere.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the action and mechanism. Every word contributes meaning, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema coverage, the description adequately explains the purpose and mechanism. Some details about output or side effects are missing, but the core functionality is sufficiently clear for an agent to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters (account and message_ids), so the schema already documents them fully. The description only restates that account is required, adding no extra semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Archive messages') and adds the mechanism ('removing INBOX label'), making it clear what the tool does. This distinguishes it from siblings like trash_emails and remove_labels by framing it as an archival operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for archiving messages and notes the account requirement, but it does not explicitly state when to use this over alternatives like remove_labels or trash_emails. There is no direct comparison or exclusion of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It conveys a read-only operation (via 'Get') and lists sample metadata fields, but does not discuss permission requirements, error behavior, or other behavioral traits. This is adequate for a simple get operation but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. It immediately states the action and resource, then provides relevant examples of returned data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description provides a clear overview of what the tool returns. It does not explicitly list all possible metadata fields, but the examples ('size, parents, export links') are sufficient for typical use cases. Sibling tools add context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the two parameters ('Account id.' and 'Google Drive file ID.'). The description adds context about the output metadata but not about the parameters themselves, so it stays at the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get'), the resource ('full metadata for a specific Google Drive file'), and provides specific return elements ('size, parents, export links'). This distinguishes it from siblings like get_drive_file_content (content retrieval) and list_drive_files (listing multiple files).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving metadata of a single, known file, but it does not explicitly state when to use it vs alternatives or mention any exclusions. It relies on sibling names and context to convey appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states the action itself without mentioning side effects, reversibility, permissions, or failure behavior. For a mutating operation, this is a significant gap, similar to the 'update_drive' calibration example.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of eight words, front-loaded with the verb 'Remove'. It is concise, with no wasted words, and the parenthetical '(account required)' is a small but useful emphasis. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (3 required parameters, no nested objects, no output schema), and the description sufficiently explains the action for an agent to select it. However, the lack of any behavioral details beyond the operation itself, and the absence of annotations, leaves some context unaddressed, so it falls short of a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters (account, message_ids, label_ids). The description adds no additional meaning beyond the schema, hence the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Remove' with the resource 'labels from messages', clearly identifying the tool's purpose. It also notes the scope 'in one account', distinguishing it from account-wide operations. The sibling tool 'add_labels' is the natural inverse, so there is no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for the operation, implying it is for removing labels from messages, which differentiates it from sibling tools like 'add_labels' and 'mark_as_read'. However, it does not explicitly state when to use this tool over alternatives or any exclusions, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds key behavioral context (appending after the last row with data), but does not disclose other important traits such as authorization needs, side effects, error handling, or behavior when the sheet is empty. It provides some value beyond the schema but is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly conveys the core functionality. It is front-loaded with the action and resource, contains no filler, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple append operation, the description covers the essential behavior (append after last data row) while the schema fully documents all parameters. No output schema exists, but the tool's return value is likely minimal. It could be slightly more complete with notes on edge cases, but for its complexity it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add new meaning to the parameters; it merely restates the concept of rows, which the schema already describes as a 2D array. It does not compensate further for any gaps because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool appends rows to a Google Sheet, specifically after the last row with data. It uses a specific verb 'append', identifies the resource 'Google Sheet', and distinguishes from siblings like sheets_write by emphasizing the append-after-last-row behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (adding rows at the end of a sheet) but does not explicitly mention when to use it over alternatives like sheets_write or sheets_update, nor does it state any exclusions or prerequisites. The guidance is inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the key destructive behavior ('Overwrites existing values'), which is important. However, it does not mention whether the operation is reversible, whether it affects only the specified range, or if authentication is required. It adds some value but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and every word earns its place. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with fully documented schema, the description plus schema covers the essential use case: writing and overwriting a range. It does not explain return values (no output schema), but that is not critical for a write tool. The lack of explicit mention of optional value_input_option behavior is compensated by the schema enum description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented with descriptions. The tool description does not add meaningful detail beyond the schema, aside from emphasizing the overwrite behavior. Baseline 3 is appropriate since the schema handles parameter semantics well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action with a specific verb and resource: 'Write values to a Google Sheet range.' It also adds the crucial differentiator 'Overwrites existing values in the specified range,' which distinguishes it from sibling tools like sheets_append.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool ('when you need to overwrite values') but does not explicitly mention alternatives or exclusion criteria. It does not name sheets_append or provide 'when not to use' guidance, though the overwrite mention offers some context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions the two time-specification modes but does not disclose return values, side effects (e.g., sending notifications), or required permissions. For a creation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains zero waste. Every sentence adds functional information about how to use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 13 parameters and no output schema, the description provides the key semantic distinction for time parameters but omits other contextual details like return value, prerequisites, or examples of typical use. The rich schema partially compensates, but the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 13 parameters with individual descriptions (100% coverage), so the baseline is 3. The description adds value by grouping the time parameters into coherent usage patterns (timed vs all-day), which is not immediately obvious from the flat schema list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new calendar event, using the specific verb "Create" and resource "calendar event". It also distinguishes the two event types (timed vs all-day), setting it apart from siblings like update_event, delete_event, and list_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear conditional guidance: use start_date_time/end_date_time for timed events and start_date/end_date for all-day events. This helps agents choose the right parameters, though it does not explicitly name alternative tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosure. It adds the key behavior of searching across all accounts when omitted, and clarifies that it searches metadata (not content). However, it does not explicitly state that the operation is read-only, nor mention pagination, rate limits, or return format, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence front-loads the core purpose ('Search Google Drive file metadata'), and the second adds the important account-merging behavior without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema), the description adequately covers what it searches (metadata) and a key behavioral nuance (account merging). However, it lacks explicit details about return fields, result ordering, or pagination, which would be useful for a tool that returns a list of files.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage of parameter descriptions, including the account-merging behavior in the account field. The description adds marginal value by clarifying that the search targets 'file metadata' rather than content, but this is not a major addition beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('search') and resource ('Google Drive file metadata'). It distinguishes itself from siblings by specifying that omitting the account parameter searches all enabled accounts and merges results, which is a unique behavior not seen in list_drive_files or get_drive_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching file metadata, and the account-merging note provides practical guidance on when to omit the account parameter. However, it does not explicitly contrast this tool with alternatives like list_drive_files, so it stops short of fully explicit when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds the important behavioral trait that omitting account searches all enabled inboxes and merges results, but it does not mention other aspects such as return format, pagination, or authentication requirements. This is minimal but not entirely absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary purpose, and contains no redundant or extraneous information. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers parameters well, but there is no output schema and the description does not explain what the search returns (e.g., list of email IDs, subjects). The aggregation behavior is helpful, but the lack of return format and limited behavioral context makes it only minimally complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for all three parameters, including the account parameter's note about aggregation. The description repeats this behavior without adding additional semantic value beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Gmail using query syntax, which is a specific verb and resource. It distinguishes itself from sibling search tools like search_drive_files and search_drafts, and the note about omitting account clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by explaining how the query parameter works and the behavior when omitting the account (aggregates all enabled inboxes). However, it does not explicitly mention alternatives or exclusions compared to sibling tools like read_emails or search_drafts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses partial-update behavior ('Only provided fields are changed') but does not mention permissions, reversibility, or what happens to omitted fields. For a mutation tool, more context would be helpful, but the description still adds meaningful behavioral information beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the action, and contains no filler. Every word contributes to the purpose and key behavioral note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 14 parameters and no annotations, the description is sparse. The schema covers per-field meaning, but the description does not address interactions like all-day vs timed fields, timezone dependencies, or default notification behavior. It is adequate for basic usage but not fully comprehensive for a complex update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of parameter descriptions, so the baseline is 3. The description's 'Only provided fields are changed' clarifies that parameters are optional partial updates, which is useful but does not provide per-parameter details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Update' with the resource 'existing calendar event,' clearly distinguishing it from siblings like create_event and delete_event. It unambiguously states the action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing calendar event' clearly implies use for modifying an existing event rather than creating or deleting. Sibling tool names make alternatives obvious, and 'Only provided fields are changed' adds context for updating only select fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses permanence and single-account scope, but misses potential side effects, authentication requirements, error behavior, or return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the operation and scope, followed by a useful pointer to ID sources. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete tool with full schema coverage, the description provides essential behavioral information (permanent, single-account, ID source). Minor gaps around return values/errors are acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description slightly reinforces the origin of draft_ids but adds no new semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'drafts', plus the scope (one or more in one account). This distinguishes it from sibling tools like delete_label and delete_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: drafts are identified by IDs returned from create_draft or list_drafts, and account is required. It does not explicitly mention alternatives, but no direct alternative exists for deleting drafts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the table is empty and inserted at the end, but does not mention side effects such as permanent document modification, error conditions, or return values. For a mutation tool, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words, front-loading the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with all parameters documented in the schema. The description covers the core purpose and location. However, the absence of an output schema and annotation means the description takes on more responsibility for explaining return behavior, which it does not address, so slightly less complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all four parameters (account, document_id, rows, columns) with 100% coverage, so the description adds no additional parameter meaning. Baseline is 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'insert' with direct object 'an empty table' and location 'at the end of a Google Doc,' clearly defining the action and resource. It distinguishes from sibling docs_append, which appends text/content, by specifying table insertion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case of adding a table to a document's end but does not explicitly compare to alternatives or state when not to use. The context is clear enough for an agent to infer, but no exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly mentions the side effect of 'storing token.json' and the exchange of an authorization code, but does not disclose potential failure modes, whether it overwrites an existing token, or prerequisites beyond what is implied by the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose and includes the key side effect. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema and no annotations, the description adequately covers the core purpose and primary side effect. It could be slightly more complete by explicitly mentioning the prerequisite relationship to 'begin_account_auth', but the context is strongly implied and sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the description need not add additional parameter detail. The description does not introduce semantics beyond what the schema already provides, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Complete'), the resource ('OAuth onboarding'), and the mechanism ('exchanging authorization code and storing token.json'). It also differentiates from the sibling tool 'begin_account_auth' by indicating completion of the flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the word 'Complete' and the reference to 'authorization code', suggesting it follows 'begin_account_auth'. However, it does not explicitly state 'use after begin_account_auth' or mention exclusions, though the sibling tool name and schema description for account_id provide strong contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It openly states the download-and-extract workflow and explains that Google Docs/Sheets/Slides are exported to Office formats before parsing. This adds context beyond a simple 'get content' line, though it stops short of detailing edge cases like OCR on images or handling of binary files. The non-destructive nature is clear from 'download' and 'extract'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every phrase adds information: the export mechanism, supported types, and the extraction result. There is no filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex but well-covered. The description explains the core behavior, supported file types, and the return value (extracted text content). Given there is no output schema, this suffices for a simple content retrieval tool. Minor gaps include not specifying how images are OCR'd or whether large files are truncated, but these are not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters ('Account id.' and 'Google Drive file ID.'), so the baseline is 3. The description adds contextual value by mentioning 'Drive file' in the purpose, which reinforces the file_id semantics, but it does not introduce any new parameter-level details beyond what the schema already provides. No additional explanation of formats or expected values is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Download a Drive file and extract its text content.' This is a specific verb+resource pair that distinguishes it from sibling tools like 'get_drive_file' (which likely retrieves metadata) and 'sheets_read' (which reads a specific Google Sheet). It also enumerates supported file types, further clarifying its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need text content from a Drive file) by listing supported formats. However, it does not explicitly contrast with alternatives like 'get_drive_file' for metadata or 'sheets_read' for structured sheets, nor does it mention exclusions or prerequisites. The guidance 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses that the tool lists all filters, not just blocked senders, which is a useful behavioral trait beyond the name. However, it does not mention return format, pagination, or any read-only guarantee, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first sentence stating the core purpose and the second providing usage guidance. Every word adds value, with no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description is fairly complete: it explains what is listed, the scope, and common use cases. However, it could be more explicit about the structure of the response, but this is minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'account' is already described in the schema with 'Account id.' The description adds no additional parameter semantics, but since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all Gmail filters for an account, which is specific and distinguishes it from sibling tools like list_accounts or get_labels. It also clarifies the relationship to blocked senders, explaining that blocked senders are represented as filters, and provides a concrete use case (finding filter_id for unblock_sender).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: to find filter_id for unblock_sender or to audit auto-trashed/archived/spammed content. It gives clear context but does not explicitly state exclusions or alternatives, hence a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the aggregation behavior when account is omitted, which is valuable. However, it does not disclose that this returns metadata (not content), pagination behavior, or that it is a read-only operation beyond the verb 'List'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and every word earns its place. It is efficient and clear without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list operation with no output schema, the description covers the essential behavior and filters. It does not describe the return format or pagination, but these are partially covered by schema parameters. The missing account aggregation nuance is a notable plus.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it mentions filter by folder or text query and account omission, but the schema already describes these parameters in detail. No additional parameter meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List Google Drive files', a specific verb+resource pairing. It adds unique scope by noting account aggregation and optional folder/text filters, which differentiates it from siblings like get_drive_file or search_drive_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use: listing files, with optional filters for folder or text. It explicitly explains the effect of omitting the account parameter, but it does not mention alternatives such as search_drive_files for broader content search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses the key aggregation behavior and filter capabilities, but omits details like default time boundaries, output format, or permissions. For a list operation, safety is implied, but transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each earning its place: the purpose, the aggregation behavior, and the filter capabilities. It is front-loaded and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 optional parameters, no annotations, and no output schema. The description covers the main filtering behavior but leaves ambiguity about what the list returns and default time-range behavior when time_min/time_max are omitted. This makes it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover all 7 parameters, earning a baseline of 3. The description adds value beyond the schema by explaining that omitting account aggregates across all enabled accounts, and explicitly confirms query as text search.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is explicit: "List calendar events" is a clear verb+resource pair. It distinguishes from sibling tools like get_event (single event) and list_calendars (calendar metadata), and adds the scoping nuance of account aggregation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: supports time range and text search, and explains the account-omission aggregation behavior. It does not explicitly name alternatives, but the context is sufficient given siblings like get_event.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It states the operation is a 'get' (read-only) and specifies the exact return contents (metadata fields). It does not mention potential errors or permissions, but for a simple metadata retrieval, the behavior is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource, then immediately lists the specific metadata fields. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description explicitly lists the return values (title, sheet tabs, row/column counts), which is sufficient for this simple tool. It fully covers the tool's purpose and outputs, with no apparent gaps given the low complexity and minimal parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters fully (account id and spreadsheet ID from URL), yielding 100% schema coverage. The description does not add additional semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'Google Sheets spreadsheet metadata', and explicitly enumerates what that includes: title, sheet tabs, row/column counts. This effectively distinguishes it from sibling tools like sheets_read (which would read cell data) and sheets_create (which creates spreadsheets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when metadata is needed) but does not explicitly contrast it with alternatives or state when not to use it. There are no exclusions or prerequisite conditions mentioned, though the context is clear enough that it is only 'implied usage' rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that each message includes attachment metadata (filename, attachment_id, size) and that content is not included, pointing to get_all_attachments. This gives a clear expectation of what the tool returns and what it doesn't.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and directly communicates the core function and a cross-reference. No fluff or redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's main purpose, the key output details, and a related next step for attachment content. Given no output schema, it compensates by explicitly stating what appears in each message.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are already well-described in the schema (100% coverage), so the description adds little beyond reinforcing that account is required. The description adds context about the output (Gmail ID) but not about the input semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get a full email thread for one account,' which is a specific verb+resource and clearly distinguishes this from sibling tools like read_emails or search_emails. It also contextualizes the output with attachment metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes 'account required' and clarifies that to read attachment content, the user should call get_all_attachments, providing an explicit alternative. It doesn't explicitly mention when not to use this tool vs other email tools, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds useful context by specifying 'all configured' (no filtering) and 'authentication/health status,' which reveals what the tool reports. It does not explicitly state the absence of side effects, but 'List' implies a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource. Every word adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters, output schema, or annotations, the description provides adequate information about what the tool returns (accounts and their authentication/health status). It is slightly vague on the exact return structure, but sufficient for a configuration listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. Per the rubric baseline is 4. The description adds no parameter details but also needs none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'all configured Gmail inbox accounts' and adds scope 'authentication/health status.' This clearly distinguishes it from sibling tools like read_emails or begin_account_auth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what it lists, but it does not explicitly say when to use this tool versus alternatives such as begin_account_auth or list_blocked_senders. There is no 'when' or 'when not' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the sort order, the specific fields returned, and hints at the tool's use in a multi-step workflow. It does not mention pagination behavior or rate limits, but for a read-only list operation this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the verb and resource, and every clause provides useful information (sort order, return fields, cross-references to other tools). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter list tool with no output schema, the description adequately covers return values and sorting. It could mention pagination limits (max 500) or clarify that it returns only drafts, but these are partially addressed by the schema and the tool name/siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters account and max_results are already fully described. The description adds minimal semantic value beyond indicating the sorting logic, which relates to internalDate rather than the parameters themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (List drafts) and the resource (drafts in an account), with a definite sorting order (oldest-first by internalDate). It also enumerates the returned fields, which distinguishes it from sibling tools like search_drafts or read_emails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool lists all drafts for an account, and notes that draft_id is intended for send_draft/delete_drafts. However, it does not explicitly name alternative tools like search_drafts for filtered retrieval or explain when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses return fields and the workflow purpose (draft_id for send_draft/delete_drafts), adding useful context. However, it does not explicitly state that the operation is read-only, nor does it describe pagination or empty-result behavior. There is no contradiction, but transparency is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action. The return fields and usage guidance are packed efficiently with no redundant information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description lists all return fields and gives clear usage guidance. It covers the essentials for a search tool but omits details about sorting or error behavior. Overall, adequately complete for an agent to use correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, with all three parameters documented. The description adds no parameter-specific information beyond what the schema already provides. Baseline of 3 applies because the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Search drafts by Gmail query string' with a specific verb and resource. It lists return fields and explicitly distinguishes from sibling search_emails by saying 'Use instead of search_emails when you need to delete or send a found draft.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use instead of search_emails when you need to delete or send a found draft.' This clearly indicates an alternative tool and the condition for choosing this one, satisfying the when/when-not/alternatives criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does mention the return values (message_id and thread_id), which is useful, but it omits the side effect that sending a draft consumes/removes the draft. This is an important behavioral trait 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no redundancy. The action is front-loaded, followed by return values and a usage hint, making every sentence earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two fully described parameters and no output schema, the description covers the purpose, how to obtain the required input, and what the return values are. It lacks only a note about the draft being consumed, but overall it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds extra context by noting list_drafts returns IDs sorted oldest-first, which helps the agent select the right draft_id and understand ordering, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'Send an existing Gmail draft by draft ID.' It clearly distinguishes this tool from siblings like send_email (which sends new emails) and list_drafts (which lists drafts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit guidance on using list_drafts to find draft IDs, including the ordering detail. However, it does not explicitly state when not to use this tool or contrast it with alternatives like send_email, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the mechanism (List-Unsubscribe), the fallback to mailto, and the return value (method used), which is meaningful behavioral context. It does not cover edge cases like what happens when no header exists, but for a relatively simple tool, it is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each adding meaningful details: the core action, the comparison to Gmail, the fallback mechanism, and the return value. It is front-loaded and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three parameters and no output schema. The description covers the main behavior, fallback, and return value, making it sufficient for invocation. It doesn't mention error handling when no List-Unsubscribe header is present, but that is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter-level context beyond the schema's own descriptions (e.g., account and message_id are not explained further). It neither enhances nor detracts from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Unsubscribe from a mailing list' by invoking the List-Unsubscribe header. It also distinguishes itself from siblings like block_sender by specifying the exact mechanism (RFC 2369/8058) and referencing Gmail's native button, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by comparing to Gmail's 'Unsubscribe' button, indicating when this tool is appropriate. However, it does not explicitly mention alternatives or exclusions (e.g., when to use block_sender instead), so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It explicitly mentions two side effects: immediate archiving and installation of a subject-based filter for future replies. It also notes the tool approximates Gmail's mute, which sets expectations. It does not cover reversibility or permission requirements, but the core mutating behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose ('Mute a conversation') and then a concise explanation of the two scope behaviors. Every word earns its place; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description covers the essential aspects: what action is performed, the two modes of operation, and the long-term effect of the filter. The input schema fully documents parameters, so no additional details are needed. This is a complete and self-sufficient description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description reinforces the semantics of the 'scope' parameter by explaining the filter behavior, but it largely duplicates what the schema already provides. No additional insight is given about 'account' or 'thread_id' beyond the schema, so the description adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool mutes a conversation by archiving it and optionally installing a subject-based filter for future auto-archiving. This specific verb+resource pairing distinguishes it from sibling tools like archive_emails or add_labels, and the addition of 'Approximates Gmail's client-side mute' provides a familiar reference point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: to mute a conversation, with the ability to either just archive the thread or also set up future auto-archiving via scope. It does not explicitly name alternatives or exclusions, but the behavioral contrast between 'archives now' and 'auto-archives future replies' implies when it is needed over simpler archive operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses side effects (saving files to ~/Downloads/mcp-attachments/), return behavior (extracted text), and supported formats. It does not mention auth requirements or failure modes, but for an extraction tool this is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the trigger condition, and every sentence adds operational value. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool handles multiple file types with extraction and local saving, and the description covers formats, ID requirement, save path, and output type. It does not mention limits or error handling, but given the absence of an output schema and the tool's moderate complexity, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, so baseline is 3. The description adds significant meaning by clarifying that email_id is the Gmail message ID (not thread ID) and points to get_email_thread output for reference. This goes beyond the schema's minimal 'Gmail message id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches and extracts content from all attachments in one shot, listing supported formats. It distinguishes itself from the sibling get_attachment by emphasizing 'all attachments' and 'one shot'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to call this whenever a thread or email shows attachments, and gives a critical usage note about using the Gmail message ID rather than the thread ID. It stops short of naming alternatives or when not to use, so it doesn't fully meet the 'explicit when/when-not/alternatives' bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it saves to ~/Downloads/mcp-attachments/ (a side effect) and returns extracted text for various formats including OCR for images. This is more than a bare fetch would imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with purpose, and every sentence contributes (purpose, usage, alternative, requirements, side effect, return format). No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema or annotations, the description covers what the tool does, when to use it, prerequisites, side effects, and return values. It is sufficiently complete for a single-attachment fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and descriptions are present, so baseline is 3. The description adds value by mapping email_id to the 'Gmail ID' from get_email_thread and reiterating the attachment_id source, which helps the agent resolve these IDs, though it mostly rephrases the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a single attachment by id' with a specific verb and resource, and explicitly distinguishes from get_all_attachments, making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance ('Use when you only need one specific file'), names the alternative ('For all attachments at once, use get_all_attachments instead'), and lists prerequisites (Gmail message ID and attachment_id).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tszaks/ghub'

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