MailOKF MCP

by pat229988

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation3/5
Most mail_* and email_* tools have clear purposes, but there is notable overlap in the sync tools (mail_sync_initial, mail_sync_now, mail_sync_all) which could confuse an agent choosing which to invoke. The 'okf_' and 'vector_' prefixed tools are also conceptually related to mail syncing/indexing, creating some boundary ambiguity between mail_sync_* and okf_rebuild_bundle/vector_index_update.
Naming Consistency3/5
The naming is mixed: email_* tools use verb_noun (email_add_account, email_get, email_send), but there are inconsistencies like email_add_account vs email_list_accounts (verb prefix on some, noun prefix on others), and mail_* tools use a different prefix entirely (mail_sync_*, mail_attachment_*). The verb placement varies (email_get before email_get_thread, email_send vs email_reply). Also tool names like 'email_add_account' have a noun in the middle rather than a resource at the end.
Tool Count2/5
38 tools is well beyond the ideal 3-15 range and leans heavy. While email operations naturally need many actions, the apparent scope includes network/auth (add_account, remove_account, test_account), lifecycle (get/get_thread/delete/batch_delete), organization (move/batch_move/label/folder), drafts/send (send/reply/forward/draft_create), attachments (three mail_attachment_* tools), plus a parallel OKF/vector knowledge system. This feels like 2-3 servers' worth of functionality compressed into one.
Completeness4/5
The surface is fairly complete for the email domain: CRUD on accounts, full email lifecycle (get/search/send/reply/forward/delete), batch operations, folders, labels, drafts, and attachments are all covered. There are minor gaps like missing undo/save-draft operations and no unread-count summary, but these are workable. The addition of OKF and vector indexing extends completeness beyond basic email into knowledge management, though it arguably over-scopes the server.
Average 2.9/5 across 38 of 38 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure, but it is silent on everything: whether this is read-only (likely, given sibling naming but never stated), pagination behavior, ordering, whether it returns full draft bodies or just metadata, or any failure modes. With zero annotations, the two-word description is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is technically short, which is good, but at 4 words it is under-specified rather than concise. A useful listing tool description could add a sentence about scope and pagination without bloat. There is nothing actively wrong with the wording, but there is also no substance to reward.
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 no output schema, no annotations, and 0% parameter coverage, this description is materially incomplete. It is a list operation on drafts (moderate complexity: likely paginated, account-scoped, returning multiple items), yet the description explains none of the return characteristics, filtering, or account requirements. For a 3-parameter tool with no structured support, this falls well short of minimum viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters, but it documents none of them. The limit and offset parameters are pagination-related, which an agent can infer from their names, but the description provides no confirmation of pagination semantics or explanation of accountId's role beyond being required. Sibling tools like email_search may offer similar parameters, leaving ambiguity about how they differ here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List email drafts' is a terse verb+resource statement but provides no scoping, filtering, order, or account context. It names the operation clearly but adds nothing beyond the tool name itself, making it barely distinguishable from the bare title. With dozens of email siblings, it fails to differentiate what 'list' returns (drafts only? saved vs unsent?) or how it relates to similar listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description does not state when to prefer this over email_search, email_get, or email_get_thread for retrieving drafts, nor mention any prerequisites such as requiring a configured account before listing. The required accountId implies account context but the description never explains this dependency.
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. The description doesn't state whether folder creation is immediately visible, whether duplicates are prevented, whether parentPath is required, what happens on duplicate names, or what the response contains. For a mutation tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's concise, though this conciseness comes at the cost of under-specification rather than being tight and complete.
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 3 parameters (2 required), no annotations, and no output schema, yet the description provides almost no contextual information. Given the complexity of folder operations (hierarchical paths, duplicates, visibility), and the large sibling toolset, this one-sentence description is materially incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 0% of parameters with descriptions, so the description must compensate. The description says only 'Create a new email folder' and gives no meaning for accountId, name, or parentPath. The agent cannot infer that parentPath is optional or how names/paths are structured without further guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new email folder' states a clear verb-plus-resource purpose. It's adequate but generic, and given the sibling email_list_folders and many email tools, it doesn't specify what kind of folder, where it can be created, or how it differs from related operations like email_move or email_label which might involve folder-like structures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided. There are many sibling email tools, but no indication of when folder creation is appropriate versus alternatives, nor any mention of prerequisites (e.g., requiring an existing account) or hierarchical folder behavior given the parentPath parameter.
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 exist, so the description carries full responsibility for behavior disclosure. It doesn't state response format, whether it returns the full email body, attachment metadata, or just headers. As a GET operation it's likely non-destructive, but nothing confirms this or explains any side effects (e.g., marking as read).
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 one short sentence with no waste. It is appropriately structured and front-loaded. However, it borders on under-specification rather than true conciseness, as it says so little it needs supplementation elsewhere.
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 modest tool with 2 required parameters, no annotations, no output schema, and no parameter documentation, the description is too thin. It doesn't cover what data is returned, how accountId and emailId relate, or behavioral specifics. With zero schema coverage and no annotations, the description should carry more informational weight.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must explain both parameters (accountId and emailId). The description does not mention parameters at all. The parameter names are somewhat self-explanatory (emailId and accountId), but there's no guidance on format, meaning, or relationship between them beyond what the raw names suggest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single email by ID' has a clear verb+resource (get email) and states the scope (single email by ID). It distinguishes from siblings like email_search and email_list_accounts, though it doesn't explicitly mention what is returned or how it differs from email_get_thread. It's a clear but minimal statement.
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 like email_get_thread, email_search, or email_get_attachment. There is no context about when this is appropriate or what prerequisites exist. The description implies one should use it when you have a specific email ID, but this is only implied.
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 full disclosure burden. It reveals this is a read operation (Get) but says nothing about what data is returned, whether thread membership is expanded/flattened, pagination behavior for large threads, or whether headers vs full bodies are included.
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?
Single sentence, zero wasted words, and the core purpose is front-loaded. This is appropriately compact, though perhaps overly terse given the total absence of other detail.
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 2-param tool with no annotations, no output schema, and 0% schema description coverage, a single sentence is inadequate. It does not explain what a thread result looks like, how it differs from fetching a single email, or any constraints. Sibling tools like email_list_folders and email_get suggest a richer context the description fails to address.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it adds nothing beyond the parameter names already visible in the schema. threadId and accountId are self-explanatory from their names, but no format, source, or relationship details are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get an email thread by thread ID' with a specific verb (Get) and resource (email thread). However, it does not differentiate from siblings like email_get, email_search, or email_get_attachment, and the distinction between a 'thread' and an individual 'email' is not clarified.
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 on when to use this vs email_get, email_search, or other retrieval tools. The description does not clarify whether this returns all messages in a thread, whether it works alongside email_get for single messages, or when one should be preferred over the other.
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 doesn't mention whether this is a read-only operation, whether it requires prior account authentication, whether it returns a flat list or hierarchical/nested folder structure, or what happens for accounts with no folders. For a listing tool with zero annotation coverage, this is a meaningful 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 one clean sentence with zero waste. It is appropriately sized for a simple tool and front-loads the core purpose effectively. The single-sentence format is acceptable, though additional contextual value could have been added without bloat.
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 it's a read/list operation with a single required parameter, the tool is relatively simple. However, with no annotations, no output schema, and a description that only states the obvious, the documentation falls short. Key missing elements include the return format, whether the listing is flat or hierarchical, authentication prerequisites, and how folders relate to labels/categories (especially given sibling tools email_get_labels and email_get_categories).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter accountId exists in the schema but its semantics are not enriched by the description. The description doesn't clarify whether the account must already be added/configured (e.g., via email_add_account), what format the ID takes, or how to discover valid account IDs. With 0% schema description coverage, the description fails to compensate for the schema's minimal parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all email folders for an account' with a clear verb (List) and resource (email folders). However, it doesn't distinguish from the sibling tool email_get_labels or email_get_categories, which also list mailbox-related collections, leaving ambiguity about what 'folders' means versus labels/categories in this mail system.
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. With sibling tools like email_get_labels and email_get_categories, an agent would benefit from knowing whether folders are distinct from labels/categories and in what scenarios to choose one over another. The description provides no when-to-use or when-not-to-use 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 full behavioral disclosure burden. 'Mark' implies mutation, but the description doesn't state whether this is reversible, requires any permissions, affects any server-side state persistently, or requires the email to exist first. It also doesn't mention the sourceFolder prerequisite for non-INBOX emails except in 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. No wasted words. However, it could be slightly more complete 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?
This is a mutating tool with no annotations, no output schema, and 6 parameters at only 17% schema coverage. The description adds minimal value: it names three boolean flags but doesn't explain the interaction between them, the conditional sourceFolder requirement, or the behavioral semantics of marking operations across the many sibling email tools in this family. A more complete description is needed for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, so the description must compensate but only lists the field names (read, starred, flagged) without explaining semantics like whether they're tri-state toggles, booleans requiring explicit true/false, or whether omitting them leaves the property unchanged. The sourceFolder parameter, which is conditionally required, gets no elaboration in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Mark an email as read/unread, starred, or flagged' uses a clear verb (mark) and resource (email) and names the three marking operations. However, it overlaps significantly with sibling tools email_batch_mark, email_label, and email_move, and doesn't distinguish itself from those 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?
No guidance on when to use this tool versus email_batch_mark (which likely marks multiple emails) or email_label (which applies labels). The description doesn't state scope (single email vs batch), prerequisites, or when to prefer alternatives.
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 does not state that moving is a mutation (irreversible action), whether permissions are required, what happens to the email's current folder states, or what the response looks like. The schema hints that sourceFolder is conditionally required for IMAP/iCloud, but the description doesn't surface this behavioral nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is appropriately short and to the point, but the description is borderline under-specified rather than deliberately concise. Every sentence is functional, yet the minimalism leaves key details out. It reads as a minimum-viable one-liner rather than a carefully crafted concise description.
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 mutation tool with no annotations and no output schema, the description needs to carry more weight. With 4 parameters, 75% undocumented, and no return/lifecycle guidance, the description is inadequate. The conditional sourceFolder requirement and IMAP/iCloud special case are the only useful context, and it comes from the schema rather than the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description must compensate, but it adds nothing about the four parameters. It doesn't explain the role of accountId, emailId, or targetFolder beyond their names. The sourceFolder's conditional requirement (IMAP/iCloud quirk) exists only in the schema, which is helpful but alone insufficient given 75% of params lack descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Move an email to a different folder' has a specific verb+resource (move email) and is functional but terse. It does not mention the accountId or emailId inputs explicitly, and among siblings like email_batch_move, email_transfer, and email_delete the differentiation is only implicit — the description doesn't clarify how email_move differs from email_batch_move (single vs batch).
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 email_batch_move, email_transfer, or email_folder_create. No context is given about prerequisites (e.g., needing email_list_folders first), nor when NOT to use it (e.g., use batch for multiple emails). The description is silent on all usage 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 carries the full burden of behavioral disclosure. 'Test an email account connection' is vague about what the tool actually does—whether it mutates state, what happens on failure, whether it blocks while testing, or what side effects (if any) occur. For a tool whose behavior is inherently unclear (what does 'testing' actually do?), this is a significant 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.
Conciseness3/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. However, it's underspecified rather than appropriately concise—one sentence that provides nearly no actionable detail. It earns a pass for brevity but not for delivering useful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity single-parameter tool with no output schema, the description is minimal. But this tool sits in a large email tool family where 'test connection' has ambiguous semantics (credential validation? SMTP/IMAP reachability? authentication?). While the complexity is low, the ambiguity problem means the description should provide more context about what testing entails and what outcome signals success, which it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there's only one parameter (accountId), yet the description provides no information about it beyond what the schema's type/title already give. The description doesn't clarify what accountId refers to in context (e.g., a recipient's account vs. the user's own configured account), which is meaningful given the email domain. With 0% coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Test an email account connection' uses a specific verb (test) and resource (email account connection), making the basic purpose clear. However, it doesn't clarify what 'test' means practically—whether it validates credentials, checks server reachability, or runs an authentication handshake. Among siblings like email_list_accounts, email_add_account, and email_remove_account, the purpose is reasonably distinct, but it lacks behavioral specifics that would fully differentiate it.
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. It doesn't state when testing is appropriate (e.g., after adding an account, before sending mail), nor does it mention prerequisites like requiring the account to already exist. Among many email tools in the sibling list, there's no differentiation or usage context 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List retained metadata' implies a read operation but doesn't specify what 'retained' means, whether returned selectors expire, whether message_id/account_id must reference existing records, or error behavior. The term 'retained' suggests some persistence model that is entirely unexplained.
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. It's front-loaded with the core action (List retained metadata) and mentions the selectors structure inline. No wasted words, though more substance would be welcome.
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 tool has no annotations, 0% parameter coverage, and a niche role in a pipeline (producing selectors). Given these gaps, the description is thin. It doesn't explain what 'retained' means, what distinguishes retained metadata from listed attachments, or the relationship to mail_attachment_stage/create siblings. An output schema exists, which slightly reduces burden for return values, but the conceptual gaps remain significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter-level detail. account_id and message_id are self-explanatory by name, but the description doesn't clarify which message/account context the list is scoped to, or whether both are required for filtering. With zero coverage, the description should compensate and provides little beyond what the schema's names already imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List retained metadata reusable as `{messageId, attachmentId, filename?}` selectors' states a specific verb (list) and resource (retained metadata for attachments). However, 'retained metadata' is vague—it doesn't clarify whether this lists attachments for a message or something else. The phrase 'reusable as ... selectors' hints at downstream use but doesn't clearly distinguish it from sibling tools like mail_attachment_stage or email_get_attachment.
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 explicit guidance on when to use this tool vs alternatives. The description mentions the output can be reused as selectors for other operations, implying a staging/pipeline role, but doesn't name any sibling alternatives or state when NOT to use this tool. 'Reusable as selectors' is the only usage hint, which is vague.
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. 'Synchronize every enabled account' gives no indication of duration expectations, rate limits, whether it can be run concurrently with other sync operations, what happens to in-progress syncs, or error behavior. For a potentially long-running batch operation touching all accounts, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short at seven words with no wasted content. However, this brevity borders on under-specification rather than effective conciseness, since it omits the parameter semantics and usage context that other dimensions need.
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 an output schema, this tool performs an operation across all accounts and has one boolean parameter that is entirely undocumented. The description fails to explain the behavioral implications of a batch sync (time cost, system load), what 'full' controls, or how to interpret the result. For a batch operation with a subtletly-named parameter, the description is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the 'full' boolean parameter. It doesn't. The description says 'every enabled account' and 'full' defaults to false, but there's zero explanation of what full vs non-full synchronization means or what toggling it does. The description adds virtually no semantic value for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Synchronize' and resource 'every enabled account', which conveys the core purpose. However, it doesn't clearly distinguish from sibling tools mail_sync_initial and mail_sync_now, which likely perform different synchronization modes. The word 'every' adds some scope specificity but leaves ambiguity about what full versus incremental sync means.
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 on when to use this tool versus mail_sync_now or mail_sync_initial. The siblings suggest different sync granularities (initial, now, all), but the description provides no comparison or exclusion guidance. An agent has no way to determine which sync tool fits a given scenario.
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 full burden for behavioral disclosure. The description does not state whether this is destructive (e.g., does it overwrite/rebuild the index?), whether it requires the vector index to already exist, whether it's idempotent, how long it might take, or what the output schema returns. For an operation affecting a vector index, this is a significant 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 efficient sentence with no wasted words. However, for a tool with no annotations and one opaque parameter, the brevity veers toward under-specification rather than genuine conciseness.
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 no annotations, an opaque undocumented parameter, and describes a complex operation (incremental index updates with a reprocess mode). The description does not explain prerequisites (validated OKF bundles), side effects on the existing index, error conditions, or output semantics. Given the complexity of index modification, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'full_reprocess' has 0% schema description coverage, and the description does not explain what this boolean controls, the difference between incremental and full reprocessing, or when each mode would be appropriate. The description adds no semantic value beyond the parameter's name itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Apply CocoIndex incremental changes from OKF files into sqlite-vec' which identifies the verb (apply), resource (CocoIndex changes), and target (sqlite-vec). It's reasonably clear but doesn't distinguish from sibling tools like vector_search or knowledge tools — the description doesn't clarify what makes this tool unique among the vector/index-related siblings.
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 doesn't mention prerequisites (e.g., that OKF files must first be validated or built via okf_validate_bundle/okf_rebuild_bundle siblings), nor does it explain when a full_reprocess would be needed instead of incremental application.
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. 'Remove' implies destruction, but it fails to disclose whether this permanently deletes the account configuration, whether it impacts synced emails, whether it can be restored, or whether any authorization is required. For a destructive mutation tool with zero annotative coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately terse — one short clause with no filler words or redundant restatements. It is maximally concise, though the brevity comes at the cost of behavioral detail.
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 destructive mutation tool with no annotations and no output schema. The one-line description is adequate only to identify purpose but fails to communicate side effects, reversibility, or data impact. Substantially more behavioral explanation is warranted for a removal 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?
The single parameter accountId is documented only in the schema (type string). The description adds nothing about what accountId represents or how to obtain it (e.g., from email_list_accounts). Schema coverage is 0%, so the description does not compensate, but with just one mutually obvious parameter, the cost is modest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action (remove) and resource (email account), which is clear enough to distinguish from email_add_account. However, it doesn't clarify what 'removing' an account entails (e.g., whether it deletes data, unlinks creds, etc.) or whether it's reversible, leaving some ambiguity about scope.
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 on when to use this tool vs alternatives. There are related sibling tools like email_add_account (the inverse) and email_test_account, but the description doesn't indicate when removal is appropriate, what prerequisites exist, or what the consequence is (e.g., data loss, breaking sync).
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 doesn't explain what 'source-backed' means behaviorally, whether this is a read-only operation (likely given 'retrieve'), what happens if the message has no knowledge record, or any error/edge-case behavior. The description adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It's efficient, though arguably so minimal that it borders on under-specification rather than genuine 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?
There is an output schema present, which removes the need to describe return values. The 2 parameters are minimal and somewhat self-explanatory. However, for a retrieval tool with zero annotations and zero schema coverage, the lack of any behavior detail (what happens on lookup failure, whether it returns all knowledge or filtered) makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain either parameter. account_id and message_id are self-evident from their names, but the description doesn't clarify the relationship between them or any format expectations, leaving the agent to infer from titles alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it retrieves a 'source-backed knowledge record for a message,' which gives a clear verb+resource. However, the term 'source-backed knowledge record' is somewhat jargon-heavy and unclear without further context, and it doesn't distinguish from the sibling tool knowledge_search.
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 on when to use this tool versus knowledge_search or vector_search. The sibling tools include several search/retrieval tools, and the description provides no comparison or exclusions to help the agent choose between them.
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. 'Regenerate' implies potentially destructive/overwriting behavior, but the description doesn't state whether existing projection data is replaced, whether it's idempotent, what happens to the bundle during regeneration, or any side effects on the account's mail data. This is a significant transparency gap for a rebuild operation.
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?
Single sentence, zero waste, front-loaded with the action verb. Descriptions this short are generally appropriately concise when schema and annotations cover the rest, which they don't here, but conciseness itself is fine at 4.
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?
An output schema exists, so return values need no explanation, but the tool is a rebuild operation with no annotations, no usage guidance, and unexplained domain terminology ('OKF projection'). For a potentially destructive maintenance operation, the description should explain prerequisites, side effects, and how it fits in the sync workflow. This is under-specified for its 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?
There is only one parameter (account_id) and schema description coverage is 0%, so the description carries responsibility for parameter meaning. The description mentions 'the canonical SQLite records' but doesn't explain how account_id scopes the rebuild or whether the account must already exist/be synced. With a single self-explanatory parameter, a baseline of 3 is appropriate, but the description adds nothing beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Regenerate the OKF projection') on a specific resource (SQLite records). However, 'OKF projection' is domain jargon that isn't explained, and the description doesn't distinguish this from the sibling okf_validate_bundle or clarify how rebuilding differs from validating. Purpose is stated but not fully accessible to an agent unfamiliar with the domain.
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 on when to use this tool versus alternatives. It does not explain when a rebuild is needed, whether it's destructive, whether it should follow validation, or when okf_validate_bundle should be used instead. The tool appears to be part of a sync/rebuild workflow but gives no 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?
No annotations are provided, so the description carries full behavioral disclosure burden. The description says 'Delete' which implies destructive behavior, but doesn't disclose whether deletion is reversible, whether permanent=true permanently removes emails, what happens to attachments, rate limits, or what the sourceFolder requirement means for certain accounts. For a destructive batch operation, this is a significant 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 efficient sentence that conveys the core purpose without filler. However, given the number of undocumented parameters and lack of annotations, the brevity comes at the cost of necessary information. It's concise but arguably under-specified for the tool's complexity.
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 mutating tool with 4 parameters, no annotations, no output schema, and only 25% schema coverage, the description is severely incomplete. It doesn't explain the permanent flag, sourceFolder requirements for IMAP/iCloud accounts, error handling, batch limits, or how this compares to email_delete. The output schema absence means the description should at least hint at return behavior. This is well below minimum viable for a complex destructive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only sourceFolder has a description). The description itself adds zero parameter semantics beyond what's in the schema. With 4 parameters and only 1 documented in the schema, the description completely fails to compensate for the undocumented parameters (accountId, emailIds, permanent). The agent has no guidance on what 'permanent' means or how accountId/emailIds should be structured.
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 (delete) and resource (multiple emails at once), which distinguishes batch operation from single deletes. However, it doesn't explicitly mention details like whether this also supports permanent deletion, which sibling email_delete might suggest. The purpose is clear enough to distinguish from email_delete but could be more specific about scope.
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 says this is 'much faster than individual deletes' which implies it should be used for bulk operations, but provides no explicit when-to-use guidance, no mention of the permanent flag trade-offs, no mention of folder dependencies (sourceFolder being required for IMAP/iCloud), and no distinction about when to prefer this over email_delete. There's no exclusions or alternatives mentioned other than the vague speed advantage.
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 doesn't state what happens to the original email (does forwarding preserve attachments? does it mark as forwarded?), whether the recipient list replaces or adds to existing, what the 'confirmed' parameter gates, or what the response looks like. For a mutation tool with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste. However, given its brevity it borders on under-specification rather than genuine conciseness — there's room to add valuable context without bloat.
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 6 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't address the 'confirmed' and 'idempotencyKey' fields which have non-obvious semantics, doesn't clarify how the body interacts with the original email, and gives no post-condition information. A forward operation has meaningful subtleties (idempotency, confirmation) that are entirely undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate entirely. The description only names the high-level action (forwarding to recipients) but provides no meaning for parameters like 'confirmed', 'idempotencyKey', or 'body' beyond their bare schema types. The 'to' array and body shape are defined structurally but their semantic role in a forward flow (editing body vs original) is unexplained.
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 'Forward an email to new recipients' clearly states the verb (forward), resource (email), and purpose (new recipients). It sufficiently distinguishes from siblings like email_send and email_reply, though it doesn't explicitly name the differentiators.
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 on when to use this tool vs alternatives like email_send or email_reply, nor any exclusions or prerequisites (e.g., whether the email must exist, whether confirmation is needed). No when-not guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided and the description is a single sentence with no behavioral disclosure beyond the literal operation. It doesn't state response format, whether labels include system labels, rate limits, or any mutation implications. For a list operation this is thin, and with zero annotation coverage, the description carries the full burden but doesn't meet it.
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 zero waste. It's appropriately terse for a simple list operation, though it could have used the compact space to add a bit more behavioral context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, no-output-schema tool this is a simple operation, so the completeness bar isn't high. However, the 'Gmail only' restriction is unexplained, no output structure is hinted at, and there's no contrast with the many sibling email tools. Given zero annotations, this is under-specified for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the single accountId parameter, but it adds no detail beyond what the schema's type 'string' already conveys. The 'email account' phrasing in the description hints at accountId meaning but doesn't clarify format (email address vs account identifier) or validate requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('labels for an email account'), with a useful scope qualifier ('Gmail only'). It provides clear purpose and distinguishes from the sibling email_list_folders, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Gmail only' qualifier conveys a limitation context, implying it should not be used for other providers. However, there's no explicit guidance on when to use this vs email_list_folders or email_get_categories, leaving the agent to infer the distinction.
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 states the tool mutates email state (add/remove labels) but doesn't disclose whether adding and removing can happen in one call, whether partial failures occur, what happens if a label doesn't exist, whether this is destructive/reversible, or effect on other metadata. For a mutation tool with zero annotation coverage, more disclosure is expected.
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 single-sentence description is efficient and front-loaded. It communicates the action and platform constraint without waste. However, it's arguably under-specified rather than properly concise—but for conciseness as measured here, brevity is a strength.
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 4 parameters, 0% schema coverage, no output schema, no annotations, and a mutation operation, the description is incomplete. It should at least clarify the meaning of addLabels vs removeLabels, note both can be used together or independently, and mention platform constraint implications. The description leaves the agent to infer parameter semantics from the schema titles alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It doesn't mention any parameters: accountId, emailId, addLabels, removeLabels. The description implies the semantics of labels (add/remove via the tool name and description) but gives no specifics about which parameters map to actions or their accepted formats. This is a significant gap given four parameters, two of which are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Add or remove labels on an email (Gmail only)' which clearly states the verb (add/remove), the resource (email labels), and an important platform constraint (Gmail only). It doesn't explicitly distinguish itself from siblings like email_mark or email_get_labels, but the action is reasonably clear. The 'Gmail only' qualifier adds specificity that helps differentiate from the broader email tooling.
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 like email_mark, email_move, or the batch operations. The 'Gmail only' note is the sole context clue. No exclusions, prerequisites (e.g., needing valid label names), or conditions (e.g., can both add and remove simultaneously) are mentioned.
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 does state that it replies to an EXISTING email, which distinguishes from creating a new send. However, it doesn't mention side effects (sending immediately vs draft), whether a 'confirmed' confirmation or idempotencyKey is needed for safe mutation, or what happens to attachments/threads. For a mutation tool with zero annotation coverage, this is a modest disclosure but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. It is appropriately front-loaded and concise, though this brevity comes at the cost of missing important nuance about parameters and usage.
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 6 parameters, 0% schema coverage, no output schema, no annotations, and a mutation operation, the tool is under-documented. The description is too thin to fully inform the agent about the confirmed/idempotencyKey gating mechanism, body format requirements, or replyAll semantics. Given the complexity and absence of structured support, it should carry more explanatory weight.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the 6 parameters. It adds no meaning beyond what the schema shows: it doesn't clarify what 'body' accepts structurally (text vs html), what replyAll does, what confirmed gates, or what idempotencyKey is for. The description adds zero parameter insight when it should be carrying a significant burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Reply to an existing email' uses a clear verb+resource structure that identifies the core action. However, it doesn't distinguish itself from siblings like email_forward, email_send, or email_draft_create, which are adjacent email-creation operations.
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 vs email_send or email_forward. It doesn't explain account setup prerequisites (e.g., needing to add an account first via email_add_account) or whether replyAll parameter exists to switch modes. No exclusions or alternative tool references 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions 'synchronization and reconciliation' but gives no detail on what side effects occur: does it clear local cache, overwrite existing data, require network access, or mutate mail server state? With zero annotations and an output schema present but unexplained, the agent cannot anticipate cost, duration, or destructive potential of this operation.
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?
A single concise sentence with no wasted words. It could be argued this is under-specified rather than concise, but as a standalone statement it communicates purpose efficiently.
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 operation is nontrivial (full sync + reconciliation with side effects) yet the description does roughly the minimum. An output schema exists, which relieves some return-value burden, but the tool's behavioral complexity—duration, data volume, error conditions, and relationship to status-tracking siblings—is not addressed. Adequate for an agent that needs only the gist, but thin given the 'full initial' scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the single account_id parameter. It is referenced implicitly by the subject 'mailbox' but the description never directly specifies account_id as the target of the sync. With only one required parameter, the baseline compensation need is modest, but the description offers no explicit mapping between the parameter and the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Perform a full initial mailbox synchronization and reconciliation' with a specific verb (perform) and resource (mailbox), and 'full initial' distinguishes from the sibling mail_sync_now and mail_sync_all. However, 'reconciliation' is vague jargon—what is being reconciled (server vs local state? duplicates?) and 'initial' is ambiguous (first-ever sync, or reset of state?) leaving moderate ambiguity about exact scope.
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 on when to use this vs siblings mail_sync_now, mail_sync_all, or mail_sync_status. The word 'initial' implies a first-time setup scenario, but the description never states that explicitly, nor does it explain when the alternatives should be preferred. There are no prerequisites, caveats, or exclusion statements.
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 doesn't mention that this is a credential-storing operation, sensitivity/security implications of handling passwords, whether adding an account triggers connectivity tests, failure behavior if the IMAP host is unreachable, or whether existing accounts with the same email are deduplicated. For an account-mutating operation with zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core purpose in the first clause and appends the important provider limitation in a parenthetical. It's efficient with no wasted words, though it could have used the word budget to add parameter or behavioral detail instead of purely conciseness.
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 9-parameter tool with 0% schema coverage, no output schema, and no annotations, the description is notably incomplete. The agent needs to know how host/port/tls/password relate to IMAP, how smtpHost/smtpPort relate to outgoing mail, what the required 'provider' values are, and what success/failure looks like. The description addresses only the provider-level distinction and leaves substantial gaps for the most complex part of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for 9 undocumented parameters including host, port, tls, password, smtpHost, and smtpPort. The description only mentions the provider types; it adds nothing about how the IMAP/SMTP fields interact, whether smtpHost/smtpPort are optional, or what TLS controls. The description names provider but not the other 8 parameters, leaving the agent to guess at semantics.
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 adds a new email account and specifies the scoping (IMAP or iCloud), with a distinct parenthetical limitation about Gmail/Outlook requiring the setup wizard. This distinguishes it from sibling tools like email_remove_account, email_test_account, and email_list_accounts. However, the purpose itself (add account) is largely evident from the name, so it's clear but not exceptional.
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 one important usage constraint: Gmail and Outlook are not supported here and require the setup wizard. While this gives meaningful when-not-to-use guidance, it doesn't explicitly name alternatives (the setup wizard) or describe broader context for when this tool should be selected over siblings like email_test_account. The guidance is implied rather than fully 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 provided, the description carries full burden for behavioral disclosure, but it only states that it marks emails 'at once' and is 'faster'. It doesn't disclose return behavior, whether marks are additive or overwrite existing states, whether partial failures occur for some emails, or the IMAP sourceFolder requirement that the schema hints at. A mutation tool with zero annotation coverage should say more about side effects and prerequisites.
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?
Two efficient sentences with no wasted words. The key distinguishing value ('much faster than individual marks') is front-loaded. However, the 'much faster' claim is unsubstantiated promotional language that could be replaced with more useful behavioral detail.
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 zero annotations and no output schema. Given 6 parameters with 83% undocumented in the schema, the description should cover: boolean semantics (true=set or clear?), omitted-boolean behavior (leave unchanged vs clear), sourceFolder requirements for IMAP/iCloud, and partial-failure handling. None of these are addressed. The description is adequate only for the simplest non-IMAP use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, so the description must compensate for the 5 undocumented parameters. It mentions the three boolean mark types (read/unread, starred, flagged) which maps to read, starred, and flagged params. However, accountId, emailIds, and sourceFolder are not explained in the description, and it doesn't clarify the semantics of the booleans (e.g., is 'true' applying the mark or removing it, and what happens when a mark param is omitted). The description adds marginal value over the sparse schema but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: batch-mark emails with specific mark types (read/unread, starred, flagged). It distinguishes from single-mark sibling email_mark by emphasizing 'multiple emails at once' and 'much faster', and from email_batch_delete/email_batch_move by naming the mark action. However, it doesn't explicitly name the sibling alternative email_mark as the single-item counterpart.
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 claims speed advantage over individual marks but provides no when-to-use guidance, no exclusions, and no mention of constraints like IMAP caveats (though the sourceFolder param hints at this in schema). It doesn't distinguish when to prefer this vs email_mark for single emails beyond the speed implication, and gives no context about behavior when mixing mark types in one call.
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's a mutating operation but the description doesn't state whether the move is atomic (all-or-nothing), what happens if some emailIds fail, whether it confirms each email was found before moving, or whether it permanently alters mailbox state. Given zero annotation coverage, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short at two sentences, with the core purpose stated in the first sentence and a value-add note in the second. No wasted words. However, given the tool's mutating nature and nuanced sourceFolder behavior, some added context could be justified, making it slightly under-specified rather than optimally 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?
This is a batch mutation tool with no output schema, no annotations, and only 25% schema description coverage. The description fails to address critical context: whether the operation is atomic, error handling for partial failures, prerequisites (sourceFolder for IMAP/iCloud), and behavior with already-moved emails. Given the tool's destructive/mutating nature and low schema coverage, significantly more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% — only sourceFolder has a description in the schema. The description itself doesn't explain any parameters beyond implying targetFolder and emailIds. While the parameter names are fairly self-explanatory (emailIds, targetFolder, accountId), the nuanced sourceFolder behavior for IMAP/iCloud is only documented in schema and not reinforced. The description adds minimal param value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves multiple emails to a folder at once, with a specific verb (move), resource (emails), and scope (batch vs individual). It distinguishes from the sibling email_move by emphasizing batch operation and efficiency. However, it doesn't explicitly name the sibling differentiation (email_move) as an alternative, only implies speed advantage.
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 says 'much faster than individual moves,' implying when to choose this over single-email moves, but that's implicit rather than explicit. There's no guidance on when NOT to use it, no mention that sourceFolder has special requirements (required for IMAP/iCloud per the schema), and no mention of batch size limits or failure behavior with partial moves.
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 state the key behavior (trash vs permanent delete), but omits important details like whether deletion is reversible, what happens to attachments, permission requirements, and the sourceFolder requirement for non-INBOX IMAP/iCloud emails. The 'permanently deletes' implication should also explain the irreversibility.
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, compact sentence that efficiently conveys the core behavior and default. It is appropriately front-loaded with no waste, though it could trade some brevity for critical detail like the permanence irreversibility.
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 mutation tool with no annotations and no output schema, the description is thin. It has 4 parameters but only 25% schema coverage, a destructive default with a permanent escalation option, and no explanation of side effects, permissions, or the sourceFolder edge case. A tool of this risk profile needs more thorough behavioral disclosure than a single clause provides.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only sourceFolder has a description). The tool description notes the 'permanent' parameter's effect and the default trash behavior, adding some meaning beyond the schema. However, it does not explain the sourceFolder requirement despite this being a subtle, error-prone parameter, and does not clarify the accountId/emailId combination beyond schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource (delete email) and clearly states the default behavior (moves to trash) versus permanent deletion. This distinguishes it from sibling tools like email_get, email_move, and email_batch_delete, though it doesn't explicitly contrast with email_batch_delete.
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 does not state when to use this tool versus alternatives like email_batch_delete. It also omits important context such as whether the permanent flag requires confirmation, and does not mention prerequisites like the sourceFolder nuance for IMAP/iCloud that appears in the schema.
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 full burden. It discloses that the return is base64 encoded data, which is useful, but doesn't mention whether the attachment data is large, whether there are size limits, what error conditions exist (e.g., missing attachment), or whether this requires prior sync. For a read operation that returns potentially large payloads, more behavioral detail would help.
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?
One sentence, zero wasted words. It communicates purpose and return format efficiently. A single sentence is appropriate for what is a straightforward fetch 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?
Given no annotations, no output schema, and 0% schema coverage, the description must do heavy lifting. It covers purpose and return format but omits how to discover attachment IDs, potential size limits, and interaction with the sync/staging tools. Adequate for a basic fetch but leaves meaningful gaps for a tool with three required parameters and no schema documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates partially. It explains that attachmentId is used to identify the attachment, and the base64 encoding note helps understand the return. However, it doesn't explain how to obtain attachmentId or how attachmentId relates to the emailId parameter—whether it's nested under email or globally unique. The required trio (accountId, emailId, attachmentId) semantics are left to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states the verb (Get), resource (email attachment), identifier used (by ID), and explicitly says the return is base64 encoded data. This is clear and specific. However, it doesn't distinguish from sibling tools like email_get, email_get_thread, or the mail_attachment_* staging tools, though the base64 return detail adds useful specificity.
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 on when to use this vs alternatives. There are sibling tools like mail_attachment_stage, mail_attachment_list, and mail_attachment_create which could overlap in purpose, but the description says nothing about when to choose this over them or about prerequisites (e.g., requiring accountId/emailId 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 full burden of behavioral disclosure. The description is minimal and discloses only that retrieval can be keyword, semantic, or hybrid. It does not disclose return format, whether results include relevance scores, what the 'refresh' parameter does behaviorally, or any side effects (e.g., whether refresh triggers reindexing). For a read/search operation, the minimal disclosure is somewhat adequate but leaves the refresh semantics unexplained.
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 efficient sentence that front-loads the core purpose. It contains zero waste and states the three modes compactly. It could arguably add more detail, but for what it includes, it's appropriately sized.
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?
While an output schema exists, the description covers only a basic search listing scenario. The opaque refresh parameter, the lack of guidance across a suite of many sibling tools (email_*, knowledge_*, vector_*), and the absence of behavioral context around search modes make this incomplete. Given 5 parameters and a large sibling toolset, the description needs more content to be fully navigable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but does not. None of the 5 parameters are explained in the description. The 'refresh' parameter is particularly opaque — a search tool with a refresh boolean needs explanation of what it refreshes. The 'mode' param has an enum in the schema, but the description names the three modes without explaining differences. Parameters like account_id, limit, and query are self-evident, but refresh is not, and the description adds zero parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Search the local knowledge corpus') and names the three retrieval modes (keyword, semantic, hybrid). It's clear about what the tool does, but doesn't explicitly differentiate from sibling tools like knowledge_get or vector_search, which appear to be related knowledge-corpus operations. The verb and resource are specific, but sibling context is not addressed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool vs alternatives. It doesn't mention that knowledge_get exists for retrieving specific documents, or how this differs from vector_search. No context is given for which mode scenarios warrant keyword vs semantic vs hybrid retrieval. The 'local knowledge corpus' scope is implied but not contrasted against 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, so the description carries the full burden of behavioral disclosure. The description doesn't explain what 'authorized file' means, what authorization is required, whether staging is reversible, whether there are storage or retention limits, or what happens to staged files that are never used. The very brief description leaves meaningful behavioral uncertainty for a tool that likely has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that states the action and return value with no filler. Front-loaded with the verb and primary action. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists which helps clarify the return shape, but this is a multi-step tool (staging, likely with confirmation flow) with zero schema coverage and zero annotations. The description doesn't explain the staging workflow, how 'confirmed' factors into it, or how staged attachments integrate with send/draft operations. For a tool with this complexity, more behavioral and workflow context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all three parameters. It mentions 'authorized file' which relates to local_path, but doesn't explain the 'confirmed' boolean flag (which appears to be a confirmation mechanism) or the optional 'filename' override. The description adds minimal value beyond listing the return shape, leaving agents to guess the purpose of 'confirmed'.
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 'Stage an authorized file and return {stagedId, filename?} for send or draft.' It uses a specific verb (stage), a clear resource (authorized file), and specifies the return value. It distinguishes from sibling tools like mail_attachment_create and mail_attachment_list by focusing on the staging action, though it doesn't explicitly name the 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?
The description notes the tool is 'for send or draft,' which provides some usage context. However, it doesn't explicitly say when to use this tool vs. alternatives like mail_attachment_create, nor when NOT to use it. It doesn't explain what distinguishes staging from creating an attachment, leaving the agent to infer the relationship between these 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, so the description carries the full burden of behavioral disclosure. It mentions account isolation, which is a useful semantic constraint, but does not disclose behavior like ranking semantics, result format, pagination, cost/latency, or what happens with empty or poor-match queries. For a search operation with zero annotation coverage, this is a noticeable 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?
Single sentence, front-loaded with the core purpose, zero filler. It is appropriately short for a straightforward search tool, though it could add a sentence of behavioral detail without becoming verbose.
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?
This is a relatively simple three-parameter tool with an output schema present, which lowers the completeness bar. However, no annotations and 0% schema coverage mean the description should explain the semantic search semantics, result behavior, and how it differs from knowledge_search. It covers the basics but leaves ranking/result details open.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'query' and 'account_id' implicitly through the account-isolation note, but provides no detail about what 'limit' does beyond schema defaults, no guidance on query format, and no semantics around result scoring or threshold behavior. The description adds minimal value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run semantic similarity search') with a clear resource ('OKF vector index') and explicitly notes account isolation. It distinguishes reasonably from siblings like email_search and knowledge_search, which are also retrieval tools, though it doesn't name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (semantic search against OKF index) and mentions account isolation as a scoping constraint. However, it does not explicitly state when to prefer this over knowledge_search, email_search, or other sibling retrieval tools, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries full burden for behavioral disclosure. It does not state whether the operation is read-only/safe, whether the account must be pre-authenticated, what happens for non-Outlook accounts, error behavior, or what the returned category structure looks like. For an account-scoped read operation, key 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys purpose and platform scope without waste. It is appropriately front-loaded with the core action. Minor room for improvement exists in adding behavioral context, but the brevity is structurally sound.
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, no output schema, and 0% parameter coverage, the description alone must make this tool self-sufficient. It does not explain the return value format, category semantics, or account prerequisites, and it leaves the distinction from sibling email_get_labels unexplained. For an account-scoped operation with zero supporting metadata, this is materially incomplete.
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 0%, so the description must compensate for the single parameter. The tool name and description make it clear 'accountId' refers to the email account being queried. While the description doesn't explicitly define accountId, the context is unambiguous given only one parameter exists whose purpose is inferable from name and tool purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('List all categories for an email account') and clearly distinguishes this tool from siblings focused on labels, folders, and threads. The 'Outlook only' qualifier adds scoping value. It slightly differs from sibling email_get_labels, which is a meaningful distinction retained by the account-scope phrasing.
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 'Outlook only' parenthetical provides a platform constraint that helps the agent decide when this tool applies. However, there is no explicit guidance on when to prefer this over email_get_labels, which is a close sibling, nor any statement of prerequisites (e.g., account must exist, must be Outlook) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses that the tool returns three categories of info but doesn't describe what 'freshness' means operationally, whether the call is read-only, whether it triggers any sync behavior, or what the output schema looks like despite an output schema being present. For a status/read tool, the absence of an explicit 'this is a read-only status check' statement is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly-written sentence that enumerates exactly what the tool reports: freshness, cursor status, and local object counts. No wasted words, no redundancy with the schema, and it front-loads the purpose. Excellent conciseness for a status-reporting tool.
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?
An output schema exists, so return value details are partly covered by structured data. The tool is simple (one param, no nested objects), and the description's three enumerations capture the core value. However, given the ambiguity around 'freshness' and the lack of any guidance about cursor semantics or when counts might be empty, the description leaves the agent to infer important behavioral context that a richer description would clarify.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 1 parameter (account_id) with 0% description coverage, so the description must compensate. While the description names three return categories, it doesn't clarify the semantics of the account_id parameter beyond what the schema provides (which is essentially just a string type named Account Id). However, with a single obvious parameter whose meaning is inferrable from the tool name and sibling tools, the low coverage poses less risk. The description adds marginally to parameter comprehension.
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 'Return freshness, cursor status, and local object counts' names a specific resource (sync state) with concrete return categories (freshness, cursor status, counts). It distinguishes itself from sibling tools like mail_sync_now / mail_sync_now_all which likely perform sync actions rather than report status. However, it doesn't explicitly differentiate from mail_sync_initial, and 'freshness' is slightly ambiguous without a definition of what qualifies as fresh.
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 on when this tool should be used versus alternatives. There's no mention of when to call it (e.g., before queries to check data freshness, after initial sync). The tool name implies it reports status but the description never states a recommended use case or lists exclusions. Given the presence of many sync-related siblings, explicit usage direction would be valuable.
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 behavioral disclosure burden. It discloses MIME preservation and the copy vs. move duality, but doesn't state required prerequisites (accounts must be configured), whether deleteAfter is non-reversible, or behavioral effects like rate limits. For a mutation-capable tool with zero annotations, this is a meaningful gap but not a dangerous one given the general wording.
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?
Single, efficient sentence with no wasted words. It front-loads the core action (move/copy between accounts) and adds the distinguishing detail (preserving raw MIME). However, some behavioral detail could be traded for the concise form without losing much.
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 complex tool with 7 parameters (5 optional) that can mutate data across accounts, has no output schema, no annotations, and minimal schema coverage (14%). The description adds nothing about the copy-vs-move mechanism (how deleteAfter interacts with move semantics), what happens to existing labels/folders, or error conditions. For a tool of this complexity and destructive potential, the description is under-specified.
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 very low at 14%, with only sourceFolder having a description. The tool description doesn't explain what sourceAccountId, targetAccountId, emailIds, markRead, or deleteAfter mean beyond their names. However, most parameter names are self-explanatory (sourceAccountId, targetAccountId, emailIds, markRead, deleteAfter). The deleteAfter and markRead semantics would benefit from explanation but their names carry reasonable meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: 'Move or copy emails between accounts while preserving raw MIME'. It clearly distinguishes from siblings like email_move (which moves within an account) and email_batch_move by specifying 'between accounts'. The MIME preservation detail adds specificity.
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 cross-account transfers but doesn't explicitly state when to use this versus email_move/email_batch_move, or when not to use it. It gives no context about account setup requirements (e.g., target account must exist first). Usage guidance is implied by the tool name and sibling grouping rather than being 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 bears the burden of behavioral disclosure. It states the tool lists accounts and reports connection status, which implies a read-only operation. However, it doesn't disclose any side effects (though none seem likely), limitations, or what happens with unconfigured/duplicate accounts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that fully states what the tool does with zero wasted words. Efficiently front-loads the 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?
For a zero-parameter, read-only listing tool, this is mostly sufficient. The description tells the agent what it will get. However, without an output schema, the agent doesn't know the exact return shape (field names, structure), and the description doesn't hint at it beyond 'accounts and connection status'. Given the simplicity, this is adequate but not exhaustive.
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 0 parameters, so there is nothing for the schema to cover beyond an empty object. The description adds value by clarifying what will be returned (accounts + connection status). With no parameters, there's nothing more needed here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: lists configured email accounts and shows connection status. Distinguishes from siblings like email_add_account (add) and email_remove_account (remove). It could be more specific about what 'connection status' entails, but the purpose is clear.
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 on when to use this tool vs alternatives. Given many sibling tools, it would help to note this is a read-only overview tool useful before account operations, but the description offers no context about use cases or when to prefer it over email_test_account or mail_sync_status.
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 usefully discloses that results are compact by default and that returnBody=true is needed for full bodies, which is valuable behavioral context. However, it does not mention anything about permission requirements, whether the operation is read-only (though 'search' implies non-mutating), pagination behavior, or what fields appear in results.
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, zero wasted words. The first sentence states the purpose, the second delivers the critical behavioral note about returnBody and context savings. Exceptionally efficient and front-loaded with the most important information.
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 14-parameter search tool with no annotations, no output schema, and 0% schema coverage. The description is far too brief for the tool's complexity. It fails to explain date parameter formats, whether multiple filters combine, unreadOnly/starredOnly/hasAttachment semantics, folder/accountId relationships, or what 'compact results' actually contain. A more complex tool with this little documentation is risky for agents to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The description explains returnBody's effect on output, which is the most valuable param hint. However, it doesn't clarify semantics for since/before (date formats?), to/from/subject/body (exact match vs contains?), filter combinations, or whether limit defaults apply. With 14 parameters and 0% coverage, more compensation was needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search emails with filters,' which is a clear verb+resource purpose. It distinguishes reasonably from siblings like email_send, email_delete, etc. However, it could better distinguish from email_get_thread and email_get, which are also read operations, and from knowledge_search which might overlap with search semantics.
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 gives good behavioral context (compact vs full results, returnBody flag) but does not explicitly state when to use this vs email_get, email_get_thread, or other search alternatives. No exclusions or alternative tool names are mentioned, leaving some ambiguity about which email retrieval tool to choose.
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 describes what is validated (frontmatter and attachment references) which gives some transparency about scope, but it doesn't disclose what constitutes a validation failure, whether this is read-only, or what the output looks like. An output schema exists which may help, but the description alone adds limited behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero wasted words. Front-loaded with the action verb and immediately states the target and scope.
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 single-parameter validation tool with an output schema, the description is minimally adequate but thin. It doesn't explain what validation results look like, what 'valid' means in this context, or how it relates to okf_rebuild_bundle. With an output schema present, return-value details aren't mandatory, but more context on validation criteria and failure semantics would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there's only one parameter (account_id). The description mentions 'one account' which maps to the single account_id parameter, providing minor contextual meaning. However, the description doesn't clarify what account_id represents (email account? OKF account?) or how to obtain it, leaving ambiguity the schema doesn't resolve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Validate') on a specific resource ('OKF frontmatter and attachment references') scoped to 'one account'. It's a single sentence with a specific verb and target, though it doesn't explicitly distinguish it from the sibling okf_rebuild_bundle which shares the OKF concern.
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 a validation use-case but provides no explicit when-to-use guidance or exclusions. Given the sibling tools include okf_rebuild_bundle (which likely rebuilds what validate checks), some guidance differentiating validation from rebuilding would have been helpful.
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. It mentions size preflight and per-file limits in the schema sub-definitions (bounded size, per-file limit) which adds some behavioral context. However, it doesn't disclose what the tool returns (attachment ID? reference?), whether creation is reversible, or storage implications. The schema definitions do add some value regarding encoding validation but the description itself adds minimal behavior beyond 'store this content'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that efficiently conveys the action and purpose. There is zero waste, and the description is front-loaded with the verb and resource. No filler or redundant phrasing.
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 creates attachment content but the description doesn't explain the returned artifact (how the agent references this attachment later in email_send or email_draft_create), the content size limits, or whether content_type defaulting behavior matters. Given it has an output schema and 3 params with zero schema coverage, more detail about the return value reference and size constraints would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description says files are 'text/base64' which maps to the two content kinds (text/base64), and the sub-definitions provide descriptions of encoding and validation. However, filename semantics (extension handling, uniqueness) and content_type behavior are not explained in the description, and the schema itself has no descriptions for those fields.
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), the resource (agent-generated text/base64 file), and its purpose (for later send or draft attachment). It distinguishes this from mail_attachment_stage and mail_attachment_list by focusing on creating inline content rather than listing/staging. Lacks explicit mention of what makes it different from email_draft_create but is adequate for the core verb+resource.
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 (creating an attachment for later use in send or draft) but doesn't explicitly state when to prefer this over mail_attachment_stage or how results connect to email_send/email_reply. It names a sibling tool implicitly ('later send or draft attachment') but doesn't provide explicit exclusions or alternative guidance for the sibling attachment 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?
With no annotations provided, the description carries the burden for behavioral disclosure. It mentions incremental vs full modes, giving some transparency into behavior. However, it doesn't state whether sync is destructive, whether it can run concurrently, rate limits, or what happens to pending changes. It doesn't contradict annotations (none exist), but could describe more.
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, dense sentence with zero filler. Every word adds value, capturing the incremental/full distinction in 8 words. Ideal 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?
Given its position among mail_sync_initial, mail_sync_all, and mail_sync_status siblings, this description could better explain where it fits in the sync lifecycle. With an output schema present and simple parameters, the description is near-adequate but misses the opportunity to clarify how 'now' differs from 'initial' and 'all'.
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 0%, so the description must compensate. It partially does by explaining the 'full' parameter as 'force a full reconciliation,' which adds meaning to the otherwise bare boolean. However, the account_id parameter is not explained beyond the schema's title 'Account Id,' which is self-explanatory. The description adds value for 'full' but not for account_id.
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 ('Run') and resource (mail sync), and distinguishes between incremental sync vs full reconciliation. It distinguishes reasonably from the sibling tools mail_sync_initial and mail_sync_all, though it doesn't explicitly call out the differences.
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 via the 'incremental vs full' contrast, and the existence of mail_sync_initial and mail_sync_all siblings suggests differentiation, but no explicit when-to-use guidance or exclusions are provided. The agent must infer the distinction between this and the sibling sync 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?
With no annotations provided, the description carries full behavioral burden once-per-send and idempotency guarantee are disclosed. It states two safety inputs are 'required' but doesn't document side effects beyond sending, error cases, or what happens on idempotent retries. The 'exactly one email' and 'reuse it only for the identical send request' hint at retry semantics without full detail.
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 (three sentences) and front-loaded with the most critical safety constraint. Every sentence contributes value: requirement, attachment selection options, and confirmation semantics. No filler or redundant restatement of the schema.
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 9 params with 6 required and no output schema, so the description carries significant load. It handles the critical confirmation and attachment complexity well. However it omits guidance on accountId selection, recipient input details, and post-send return behavior, leaving the agent to guess several non-schema-documented aspects for a high-stakes irreversible 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?
Schema description coverage is only 22%, so the description must compensate for undocumented parameters. It does explain the three attachment input shapes and the confirmed/idempotencyKey semantics, which adds value. However, it doesn't clarify accountId, recipient format, or body fields beyond what the schema's basic names imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Send exactly one email') and immediately emphasizes the safety precondition of explicit confirmation. It clearly distinguishes from siblings email_draft_create (draft vs send) and email_reply/email_forward by establishing this as the final send action.
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?
Provides explicit when-not conditions requiring confirmed=true and nonblank idempotencyKey. Offers distinct attachment selection paths (mail_attachment_list vs mail_attachment_stage/create vs localPath) with named sibling tools, giving the agent concrete prerequisites and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose two important behaviors: creation is idempotent when the key is reused, and retries return the 'durable prior result.' However, it does not describe the return value shape, whether this creates a provider-side draft vs. local, rate limits, or what happens on failure. Given zero annotation coverage, the description gives modest context but misses the opportunity to explain what the tool returns or persists.
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 two-sentence, tightly written block with no wasted words. It front-loads the primary action ('Create exactly one provider draft') and packs essential constraints (idempotency, retry behavior) into the second sentence. It could arguably be slightly more comprehensive given the tool's complexity, but every existing sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 params, 3 attachment shape variants, no output schema, no annotations), the description covers idempotency behavior and attachment modes but leaves gaps: it doesn't explain the return value, whether email addresses require validation, or how drafts interact with email_draft_list for retrieval. The complexity warrants more documentation than is provided, though the description covers the most critical idempotency constraint.
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 only 17%, so the description must compensate, and it partially does by explaining the three attachment shape options (retained, staged, confirmed local) and the critical idempotencyKey semantics ('reuse it only for the identical draft'). The description adds meaning to idempotencyKey beyond the schema's 'Required nonblank retry key.' However, it doesn't add semantic depth to parameters like accountId, to, subject, or body, which remain schema-only. The description partially compensates for the low schema coverage where it matters most.
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's function: 'Create exactly one provider draft' with the specific scoping 'exactly one' and optional attachment handling. It identifies the resource (draft) and the verb (create), and the idempotencyKey requirement distinguishes this tool's behavior from siblings like email_send or email_draft_list. The precision of 'exactly one provider draft' conveys that this creates a draft at the provider level, which distinguishes it from local staging operations.
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 usage guidance: 'A nonblank idempotencyKey is required; reuse it only for the identical draft so retries return the durable prior result without creating a duplicate.' This clearly tells the agent when to use the tool (to create a draft) and the critical constraint (reuse key only for identical drafts to leverage retry semantics safely). It also defines the attachment modes (retained, staged, or confirmed local) which sets up the when/which selection criteria against sibling attachment-stage tools.
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:

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

Score Badge

Copy to your README.md:

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

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/pat229988/OKF_MAIL'

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