email-mcp-server
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation3/5
Some tools overlap heavily: set_flag and pin_email both star/flag emails; archive and move_email both move emails (archive is a special case of move); manage_labels and create_label both handle labels. The email_id format is consistently documented but the overlapping actions create ambiguity.
Naming Consistency4/5Most tools follow a clear verb_noun pattern (list_inbox, read_email, send_email, save_draft, create_label). Minor deviations: manage_labels is verb_noun but generic, get_account_status/configure_account are consistent, but mix of get_ vs list_ and set_flag vs pin_email is slightly inconsistent.
Tool Count3/530 tools is on the heavy side for an email server, but the domain is broad (account config, send/receive, folders, labels, threads, attachments, flags). Still, several tools could be consolidated or removed.
Completeness4/5The surface covers core email workflows well: reading, sending, drafting, replying, forwarding, searching, folders, attachments, threads, labels, and account config. Minor gaps: no delete permanently, inbox refresh or mark-as-spam operation, but agents can work around these.
Average 3.6/5 across 30 of 30 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 63 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.jsonto 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. It mentions the IMAP-to-folder mapping but does not explain behavior on duplicate names, whether the operation is idempotent, what permissions are required, or what the response indicates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler words, and the core meaning is front-loaded. It is efficient, though slightly under-specified for a tool with no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter create operation with an output schema, the description is minimally viable. However, the absence of behavioral details and usage guidance leaves gaps around edge cases like duplicate labels and relationship to related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not elaborate on the 'name' parameter beyond implying it is the label name. Given the IMAP mapping note, the agent might infer naming rules, but constraints, format, and uniqueness are left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the resource (label), and adds useful context that labels are mapped as folders in IMAP. It is distinct from broader sibling tools like manage_labels, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 related tools like manage_labels or list_folders. The description implies a simple create operation, but it does not state prerequisites, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 two behaviors (auto-generating quoted block and filling recipient) but is silent on whether the reply is actually sent or merely prepared as a draft, and it does not describe side effects, errors, or permission requirements. This is a meaningful gap for a mutating email 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler: it states the core purpose, the key behavior, and the one non-obvious parameter format. It is concise but not structured into explicit sections, which is why it is a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description should clarify expected return values and side effects. It does not explain whether the email is sent immediately or saved as a draft, nor does it route the agent to sibling tools such as send_email or save_draft. The description is too thin for a tool with side effects and three parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds real value for email_id by specifying the folder:uid format with an example (INBOX:1), which the schema does not provide. However, it does not add any meaning for the body or cc parameters beyond their names and types, so it only partially compensates for the schema's low description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '回复邮件' (reply email), clearly stating the verb and resource, and adds the distinctive behavior '自动生成引用块并填收件人' (automatically generate quoted block and fill recipient), which separates it from a plain send_email. It does not explicitly name or contrast sibling tools, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the verb 'reply' and by the instruction that email_id must reference an existing message in folder:uid format. However, there is no explicit statement of when to use this tool versus alternatives like send_email or save_draft, nor any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It usefully mentions that a quote block is automatically generated and specifies the email_id format, but it does not disclose whether the email is immediately sent versus creating a draft, whether additional recipients are validated, or what side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the core purpose, then adds the quoting behavior and the critical email_id format. There is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the most critical invocation detail (email_id format) and a key behavioral trait, which is adequate for basic usage. However, it lacks guidance on when to use the tool versus siblings and does not clarify sending semantics or prerequisites, leaving some gaps for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 adds crucial meaning for email_id by specifying the folder:uid format with an example, but it does not add semantic guidance for to or body beyond what their names and schema types already convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action '转发邮件' (forward email) and identifies the resource, with an additional behavioral detail about automatically generating a quoted block. It distinguishes the tool from siblings by name and action, though it does not explicitly call out the difference from reply_email or send_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use forward_email versus alternatives like reply_email, send_email, or save_draft. The context that a user wants to forward rather than reply or compose is only implied, and no exclusions or selection criteria are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It does disclose pagination and unread/sender/folder filtering, which are key behaviors for a ler tool. It dose not explicitly state that it is read-only or describe ordering/limitations, but listing by nature implies no mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence, front-loaded with the action and followed by the key filter capabilities. No filler or redundancy; every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter list tool with no annotations, the description is minimal but not severely incomplete: pagination and filters are covered, and an output schema exists to describe return values. It lacks usage routing and explicit side-effect clarity, so it is adequate with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Scheam description coverage is 0%, so the description must compensate. It maps partialy to three of five parameters: unread_only ('未读'), from_emails ('发件人'), and folder ('文件夹'), but it does not explain page or page_size beyond the generic word '分页'. The paramter names and defaults are fairly self-explanatory, keeping this at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource ('分页列出邮件' — list emails in pages) and names the main filtering dimensions. However, it does not explicitly distinguish this tool from sibling tools such as search_emails or list_drafts, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Ther is no guidance on when to use this tool instead of search_emails, list_drafts, or other siblings. No exclusions, preequisites, or alternative routing are mentioned; the filters imply a browsing use case but do not state it explicitly.
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 exist, so the description carries the full disclosure burden. It adds a useful behavioral fact — email_id is location-based (folder:uid) — which implies the identifier changes once the email is moved. However, it says nothing about the operation's mutating consequences, reversibility, or permissions, which for an un-annotated mutation tool is a notable 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler; the action is front-loaded and the format note is essential rather than decorative. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-required-param move operation with an output schema present, the description is reasonably close to sufficient. The remaining gaps — dest_folder's expected format and the post-move identity change — are modest but real. An agent could still invoke it incorrectly by passing an invalid dest_folder value, so a 3 is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must compensate, and it fully documents email_id's format (folder:uid) with a concrete example (INBOX:1). But dest_folder receives no semantic guidance whatsoever — format, allowed values, and naming conventions are left to inference. Compensation is partial, so a baseline-adjusted 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear, specific action — moving an email to a specified folder — and the tool name supplies the implied resource (email). The phrase '指定文件夹' (specified folder) distinguishes it from fixed-destination siblings like archive and trash_email, though those siblings are never named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when move_email is the right choice. There is no mention of alternatives (archive, trash_email, manage_labels), no preconditions, and no statement of what distinguishes a general folder move from fixed-destination operations. The only context clue is the email_id format note, which is parameter semantics rather than usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the disclosure burden. It mentions the default flag behavior and the email_id format, which adds value beyond the tool name. However, it does not state effects such as replacing existing flags, permission requirements, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with no filler. It front-loads the action and includes the two most important invocation details: the default flag and the email_id format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has only two parameters, and has an output schema, so the description covers the main calling pattern. It omits full flag parameter semantics and any usage exclusions, making it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 clearly defines email_id as folder:uid with an example and confirms the default \Flagged flag. However, it does not explain which other flag values are accepted or how to specify a non-default flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (设置/ set) and resource (邮件标记/ email flag), and adds the key detail that email_id must be folder:uid. It clearly identifies the tool's purpose, though it does not explicitly differentiate it from sibling tools such as mark_read or pin_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, prerequisites, or alternatives are provided. The description gives formatting details but never explains when to choose set_flag over related email actions 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. The verb '返回' indicates a read-only operation, which is useful, but the description does not state any side effects, authentication requirements, or whether the information is real-time or cached. For a simple no-parameter getter this is adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear phrase with no filler. Every element contributes meaning, and the core action and target resource are front-loaded. It is appropriately sized for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's very low complexity, zero parameters, and presence of an output schema, the description is nearly sufficient. However, it lacks any guidance on when this choice is appropriate compared to get_account_status or configure_account, and it does not clarify whether this is a lightweight identity lookup or a more involved call. This is acceptable but leaves room for an agent to mis-select it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is essentially an empty object, so there is nothing for the description to clarify. Per the baseline guidance, a zero-parameter tool gets a baseline of 4; the description does not need to add parameter-level detail because there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('返回' / returns) and a clear resource ('当前账号身份信息' / current account identity information), making the tool's function immediately understandable. It does not explicitly distinguish itself from siblings like get_account_status, but the resource scope is clear enough to separate it from most email 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as get_account_status, configure_account, or test_email_connection. No context is provided about prerequisites, such as whether an account must already be configured or authenticated. The zero-parameter shape makes misuse less likely, but the tool description still leaves selection entirely to inference.
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 behavioral transparency burden. It discloses the core action and the parameter format, but does not mention side effects, idempotence, reversibility, required permissions, or response behavior. This is thin for a state-mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the action front-loaded and the parameter format immediately following. There is no filler, redundant wording, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The one-parameter input contract is explained well and an output schema exists, so return-value details are not necessary. However, the description lacks usage differentiation from siblings and provides almost no behavioral context beyond the action, leaving a small but noticeable completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description fully compensates for the only parameter by defining the email_id format as folder:uid and giving a concrete example (INBOX:1). This is exactly the kind of parameter-level guidance an agent needs to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('标记已读' / mark as read) and includes the required resource format. It is not a bare tautology because it also specifies the email_id format with an example. However, it does not explicitly differentiate itself from sibling tools like mark_unread or set_flag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as mark_unread, read_email, or set_flag. It does not state exclusions, prerequisites, or conditions that would help an agent choose this tool over a sibling.
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 the full behavioral burden. It states the core state change but does not disclose idempotency, permission requirements, effects on already-unread messages, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence that leads with the operation and then gives the parameter format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has one parameter plus an output schema, and the description covers the required format. However, the lack of usage guidance and behavioral side-effect detail leaves gaps for an agent deciding when to call this versus mark_read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, and it does: it explains the email_id format (folder:uid) and gives an explicit example (INBOX:1), which the schema alone does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation, '标记未读' (mark as unread), on an email identified by email_id. It is clear but does not explicitly distinguish this from the sibling mark_read, relying on semantic opposition rather than a direct comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use mark_unread versus mark_read or read_email, and no conditions or prerequisites are stated. The only extra context is the email_id format, which supports invocation but not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose a key limitation: execution only occurs while the server process is alive. This is valuable and beyond what the schema provides, but it does not address other behavioral aspects such as persistence, cancellation, or errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It front-loads the core purpose ('定时发送') and then packs the most critical behavioral and parameter caveats into the parenthetical. Efficiency is strong, though it could be slightly more structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values need not be explained. The description covers the most critical constraints (send_at ISO format, server lifetime, to required). However, it misses some context such as whether scheduling persists across restarts, how conflicts are handled, or any auth requirements. It is acceptable for a simple tool but has clear gaps for a scheduling feature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 adds crucial semantics for send_at (ISO time) and a non-empty constraint for 'to'. However, it leaves subject and body undocumented, and it doesn't explain the format of 'to' beyond non-empty, even though the schema shows it as an array of strings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states '定时发送' (scheduled send), which clearly indicates the tool's function is to schedule a send rather than send immediately. This differentiates it from immediate siblings like send_email and batch_send, though it does not explicitly name the email resource or distinguish itself from other scheduling-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for delayed sending via the phrase '定时发送', and the parenthetical about server process lifetime provides an important condition. However, it does not explicitly state when to choose this over alternatives like send_email or batch_send, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden, but '列出草稿' only conveys a read/list action with no mention of side effects, ordering, or return behavior. It is adequate for a simple read-only operation but adds no detail beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase with no redundant content. It is appropriately sized for a no-argument list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the operation, zero parameters, and presence of an output schema, the description covers the core invocation needs. It could be more helpful by noting how drafts differ from inbox items, but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description does not need to explain any. The baseline of 4 applies because there is nothing for parameter documentation to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出草稿' clearly states the operation (list) and the resource (drafts), matching the tool name without being purely tautological. However, it does not explicitly differentiate from sibling tools like list_inbox, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as list_inbox or search_emails. The usage context is only implied by the name, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning read-only nature, return format, ordering, nesting behavior, or any side effects. For a listing tool this is a notable but not severe 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single accurate sentence with no filler. For a zero-parameter tool, this level of conciseness is appropriate and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, an output schema exists, and there are no parameters, the description is nearly complete. The only minor gap is the lack of context about folder hierarchy or how this relates to sibling tools, but that does not prevent correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to explain. The baseline of 4 applies because the description cannot add meaning beyond what the empty input schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('列出' = list) and a specific resource ('所有文件夹' = all folders). It is understandable on its own, but it does not explicitly differentiate this tool from sibling tools like list_inbox or manage_labels, which could also relate to 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: an agent would use this tool when it needs to list all folders. However, there is no explicit guidance about when to prefer it over alternatives, and no mention of related tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral-transparency burden. It does add a useful non-obvious constraint: delete requires name. The contrast between list and delete signals read versus destructive behavior. However, it does not disclose permissions, reversibility, failure behavior, or what the list action returns, leaving some uncertainty for a mutation-capable tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one compact sentence with a clear semicolon-separated structure. Every element adds value: the resource, the two actions, and the name requirement for deletion. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema, the description covers the core invocation requirements: which actions are available and when name is needed. It does not explain return values or error conditions, but the presence of an output schema lessens that need. The main gap is the lack of any relationship to sibling create_label, though this tool's own usage is still reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 effectively documents the possible action values ('list', 'delete') and clarifies that name is required specifically for delete, which is the most important semantic detail given name is optional in the schema. It does not define what name represents beyond the delete context, but for a two-parameter tool this is mostly sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '标签管理' (label management) and then narrows the purpose by enumerating the supported actions: 'action=list 列出, action=delete 删除'. This is a specific verb-plus-resource statement that distinguishes the tool from the sibling create_label, though it does not explicitly name that sibling or state that creation is out of 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to choose this tool over alternatives like create_label. It states the action values but not the situations that call for list versus delete, nor any exclusions such as 'use create_label for creating labels'. The agent must infer usage entirely from the action 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 are provided, so the description must carry the behavioral disclosure burden. It mentions the email_id format but does not describe side effects, reversibility, or permission requirements. The action implies a state change, but additional behavioral context is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and immediately provides the parameter format. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and an output schema exists, so return-value explanation is unnecessary. The description covers the core action and the key parameter requirement, but lacks usage context and alternative routing, leaving a minor gap for an agent deciding between this and similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds the critical format 'folder:uid' with anexample 'INBOX:1', which is essential for correct invocation. This fully compensates for the schema's bare string type definition for the sole parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action, '置顶/星标邮件' (pin/star email), and identifies the resource. The verb and object are specific, but it does not explicitly differentiate this from sibling tools like set_flag, which could perform a similar star operation, so it is not fully distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as set_flag or other email management tools. The description only provides the action and parameter format, with no mention of suitable scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses the key timed behavior and the email_id format, but does not mention whether the email is immediately read/unread, whether the snooze is cancellable, or any side effects beyond the future unread flag.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single compact sentence with two purposeful clauses: the action+time behavior and the parameter format. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with an output schema, the description covers purpose, behavior, and parameter formats. It lacks usage guidance and immediate-state details, but is mostly complete for straightforward invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates for both parameters: until is specified as ISO time, and email_id follows folder:uid with example. This exceeds the bare schema titles, though timezone or example for until is not given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('延后提醒' – snooze reminder) and adds a concrete behavioral detail (到期重新标记未读 – re-marks as unread when due). It is distinct from any sibling tool, though it is terse and does not explicitly name 'email' as the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to choose snooze_email over siblings like mark_unread or schedule_send. The description only provides format constraints and does not state use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose a key behavioral constraint—only the mailto List-Unsubscribe method is supported—which is useful. However, it does not state side effects (permanently removing the subscription), failure behavior when no appropriate header exists, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one terse sentence that front-loads the core mechanism and the key limitation (mailto-only) before giving the parameter format. Every element earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers the purpose, the method constraint, and the parameter format. It is slightly incomplete because it omits failure behavior (e.g., when no List-Unsubscribe header exists) and usage guidance, but the overall complexity is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero description coverage, but the description compensates by specifying the required email_id format ('folder:uid' with the example 'INBOX:1'). This is directly actionable for the agent, though it does not define what 'folder' refers to beyond the example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('退订' / unsubscribe) and a specific resource: the email identified by email_id, using the List-Unsubscribe header. It clearly communicates the mechanism and scope, but it does not explicitly differentiate from a similar sibling tool, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor any exclusions or prerequisites (e.g., the message must have a mailto List-Unsubscribe header). The agent must infer usage from the name and terse description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return format (base64 content) and a key format constraint for email_id. It does not mention possible errors, authorization needs, or side effects, but the operation appears read-only and the disclosed details add meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that leads with the action, then gives return format and parameter format. Every part earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and the description covers the core invocation details, including the required email_id format. The main gap is the lack of a pointer to get_attachments for obtaining part_id, but this does not block correct invocation when part_id is already known.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 adds useful meaning for email_id ('folder:uid, e.g., INBOX:1') and identifies part_id as the attachment identifier used for download. It does not explain how part_id is obtained or what its format looks like, leaving part of the burden unmet.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('download attachment by part_id') and resource, and adds that it returns base64 content. It does not explicitly differentiate from the get_attachments sibling, but the download-vs-list distinction is reasonably implied by the wording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: you need an email_id and part_id, and it provides the email_id format. However, it does not explicitly mention that part_id likely comes from get_attachments, nor does it state when not to use this tool in favor of a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does clarify that the tool fetches the entire thread, not just a single email, which is useful. However, it does not mention whether the operation is read-only, potential side effects, authentication requirements, or error behavior, though '拉取' implies a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the main action and appends the critical parameter format. There is no redundancy or filler; every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description covers the essential parameter semantics and thread scope. However, it lacks usage context relative to sibling tools and any explicit note about the read-only nature or error conditions, so it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero description for email_id (0% coverage), making this the only source of parameter meaning. The description specifies the exact format 'folder:uid' and gives a concrete example 'INBOX:1', which is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (拉取/fetch) and a specific resource (整条会话线程/entire conversation thread), and even adds the required email_id format. It clearly identifies what the tool does, but does not explicitly distinguish it from sibling tools like read_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as read_email or search_emails. The description only states the core function and parameter format, leaving usage decisions entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and it does disclose the key behavioral trait: archiving moves the email into All Mail, clarifying that it is not deletion. However, it does not mention side effects such as removal from the inbox, label behavior, reversibility, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no wasted words. It front-loads the core action and destination, then appends the critical parameter format with an example, making it maximally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter mutation tool with an output schema, the description covers the action, destination, and input format. It is slightly incomplete on behavioral caveats like reversibility or inbox removal, but those are secondary given how clear the core semantics is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a bare string field with 0% coverage, but the description fully compensates by specifying the exact format 'folder:uid' and giving the concrete example 'INBOX:1'. This is precisely the information an agent needs to construct a valid email_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource combination: '归档' (archive) with the explicit behavior '移入 All Mail'. It clearly defines the action and target, and implicitly distinguishes itself from trash (deletion) via the All Mail destination, but it does not explicitly name or contrast sibling 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what archiving does but gives no guidance on when to use it versus alternatives like trash_email or move_email. There is no explicit context, precondition, or exclusion to help the agent select this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It usefully reveals that the response includes a configured boolean, missing fields, and account information while explicitly excluding keys/secrets ('不含密钥'). It implies a read-only status check, which aligns with the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the purpose and then lists the key output fields. Every element earns its place, with no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status-checking tool with an output schema and no secrets disclosure, the description is largely complete. It covers the main return components and the security-relevant exclusion of keys. It does not mention relationships to sibling tools, but this is not essential for a call with no arguments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4; there is no parameter information for the description to add. The description instead clarifies what the tool returns, which is the only semantically relevant content for invoking it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('查看') and resource ('邮箱配置状态'), and enumerates the exact return fields: configured boolean, missing fields list, and configured account info without secrets. It clearly identifies what the tool reports, though it does not explicitly distinguish itself from sibling tools such as get_account_info or test_email_connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over alternatives, such as configure_account or test_email_connection. The intended use is implied by the name and phrasing, but there are no explicit context cues, exclusions, or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful constraints: max 20 per batch, rate limits, and empty-to rejection. However, it does not mention what happens on partial failure, whether the entire batch is rejected if one address is invalid, or any retry/idempotency behavior, which are important for a batch operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the core operation, then attaches the most important operational limits in parentheses. Every clause adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple batch tool with three parameters, the description covers the main operational constraints (batch size, rate limits, required non-empty recipients). An output schema exists, so return-value documentation is not required here. The main omission is failure-handling behavior, but overall the description is sufficiently complete for basic agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'to' cannot be empty and that subject/body are shared template fields ('同模板'). It does not detail the format of 'to' items or any other parameter-specific expectations beyond the empty check, leaving some semantic gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states '同模板批量发送' (same-template batch send), naming a specific verb (batch send), resource (emails), and key distinguishing trait (same template). This separates it from single-send tools like send_email without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides constraints such as a maximum of 20 per batch, sending frequency limits, and a rejection of empty 'to' lists. However, it does not explicitly state when to choose this tool over send_email, schedule_send, or reply_email, leaving the usage selection somewhat implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It correctly states the operation (list metadata) and the required email_id format (folder:uid with example INBOX:1), but it does not mention side effects, permission needs, or error behavior. For a read-only listing tool, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no filler. It front-loads the action and resource, then immediately provides the essential input format information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, the description covers the only non-obvious input detail (email_id format) and need not describe return values. The main gap is the lack of any usage guidance or distinction from sibling tools, which is a minor omission given the highly self-descriptive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the only source of semantic meaning for the single parameter. It provides a clear format contract (folder:uid) and a concrete example (INBOX:1), adding substantial value beyond the bare string type in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('列出' / list) and a specific resource ('附件元信息' / attachment metadata), clearly indicating the tool lists attachment metadata for a given email. The word 'metadata' also distinguishes it from the sibling download_attachment, which implies retrieving actual file content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as download_attachment, read_email, or get_thread. The description gives context about the input but does not mention any exclusions or selection criteria among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
没有 annotations，因此描述承担了行为披露责任。它补充了“立即投递”、to 不能为空、cc 可选以及人工确认时应改用存草稿等行为信息。但未提及发送失败行为、权限要求或幂等性等细节，信息有限但不算误导。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
描述只有一句话，核心信息“直接发送（立即投递）”前置，随后是参数约束和替代方案，没有冗余内容，每个部分都有价值。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
对于简单的发送邮件工具，描述已覆盖关键调用前提（to 必填、cc 可选）、行为特征（立即投递）和替代路径（save_draft），且存在输出 schema 无需赘述返回值。缺少个别的失败或重试说明，但整体足以支持正确调用。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema 描述覆盖率为 0%，描述本应充分补偿参数语义，但只说明了 to 不能为空、cc 可选，这些信息大多已隐含在 schema 的 required 和 default 中。subject 和 body 的格式或含义没有额外说明。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
描述以“直接发送邮件（立即投递）”明确说明了动作、对象和即时性特征，并用“如需人工确认请改用 save_draft”与兄弟工具做了区分。即使不看工具名，也能准确理解该工具的用途。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
描述明确给出了人工确认场景下应使用 save_draft 的替代方案，并通过“立即投递”暗示了与定时发送等工具的差异。但没有显式说明何时使用 schedule_send 或 batch_send，缺少系统性排除。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly discloses that the operation is a soft delete (recoverable) and that the email is moved into the trash, which is key behavioral context for a mutation. It does not cover permission requirements, but the essential consequence is communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no fluff: it front-lloads the action and follows with the parameter format. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description covers the action, the behavioral trait of soft deletion, and the exact parameter format. The main gap is the lack of usage guidance relative to sibling tools, which is captured under usage guidelines; otherwise the description is complete for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only specifies a string parameter with no description, so the description must compensate. It precisely defines the required format 'folder:uid' with a concrete example 'INBOX:1', giving the agent everything needed to construct a valid email_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: move an email into the trash, and adds the nuance 'soft delete' which distinguishes it from permanent deletion. It does not explicitly reference sibling alternatives like archive or move_email, so differentiation from similar actions is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use trash_email versus alternatives such as archive, move_email, or mark_read. The description only explains what the tool does, leaving the selection decision entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses three behavioral traits: auth_secret is sensitive and requires user consent before writing, the configuration takes effect immediately after writing, and it persists to .env. It stops short of describing overwrite/re-run behavior or connection validation, but the key side effects and consent requirement are stated explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence front-loads the purpose and then chains when-to-use, the consent requirement, and the persistence effect without filler. Every clause earns its place, making the description informative yet compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, invocation timing, secret sensitivity, immediate effect, and persistence, while the output schema handles return values. However, it leaves parameter semantics largely undocumented and does not state what happens when the tool is re-run over an existing configuration, which is relevant for a persistent config tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 10 parameters, but it only provides a coarse IMAP/SMTP grouping and flags auth_secret as sensitive. Parameters such as sent_folder, auth_mode, imap_port/smtp_port defaults, and the ssl booleans remain unexplained, leaving an agent to guess at their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: '配置邮箱账号（IMAP/SMTP 凭据）' (configure email account with IMAP/SMTP credentials). This clearly scopes the tool to initial account setup, which no sibling such as test_email_connection, get_account_status, or get_account_info covers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use context: '首次运行或配置缺失时调用' (call on first run or when configuration is missing). It does not name alternatives or exclusions, but none of the 29 siblings performs configuration, so the guidance is sufficient for an agent to select this tool at setup time.
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 states the action is '读取' (read), implying a non-destructive operation, and adds the email_id format as behavioral context. However, it does not disclose potential errors, authentication requirements, or rate limits, and does not explicitly confirm the read-only nature beyond the verb. This is minimal but adequate for a simple retrieval operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action ('读取原始 RFC 822 邮件头') and then attaches the parameter format. Every word earns its place; no redundancy or filler exists. It is compact and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool with an output schema, the description covers the essential context: what the tool returns and how to specify the target email. It lacks explicit guidance on when to choose this over sibling tools, and omits behavioral details like error handling, but the output schema and simple complexity keep the gap small.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, leaving the description as the only source of parameter meaning. The description compensates well by explaining the expected email_id format ('folder:uid, such as INBOX:1'), providing a concrete example. This adds significant value beyond the bare schema property definition, though it does not elaborate on edge cases like invalid folder or UID handling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: '读取原始 RFC 822 邮件头' (read raw RFC 822 email headers). This clearly distinguishes it from sibling tools like read_email or get_thread, which imply reading full content or thread data. The resource and action are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying 'raw headers' and gives the email_id format with an example, which is a practical guideline. However, it does not explicitly state when to use this tool versus alternatives such as read_email or search_emails, nor does it provide exclusion criteria. The usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It reveals a non-obvious behavior: the tool does not send the email itself; it only stores a draft that must be confirmed and sent manually. It does not mention permissions or response details, but the most important behavioral trait is explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The whole definition is one compact sentence with the main action front-loaded and the manual-send caveat clearly attached. Every clause adds useful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and no annotations, so return values need not be described, but parameter semantics are only partially covered. The key behavior is clear, yet some edge-case clarity about required fields and sibling routing is missing. Adequate, but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 0% description coverage, so the prose must explain the parameter semantics. It clarifies that 'to' may be empty and 'cc' is optional, but it leaves 'subject' and 'body' unexplained and does not state that the 'to' key is still required even if the list is empty. This is only partial compensation for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: save a draft into the Drafts folder. It also explicitly says sending happens manually after human confirmation, which clearly distinguishes this tool from send_email and schedule_send in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear practical context: use this to prepare a draft for later manual sending, and recipients can be added later because 'to' may be an empty list. It doesn't explicitly name alternatives or say when not to use it, but the workflow guidance is sufficient for basic routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It clearly states this is a read operation and specifies what is returned: plain-text body plus attachment metadata. It also documents the expected email_id format. It does not mention error behavior or explicitly state that no state changes occur, but 'read' and the output description cover the core behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence delivers the tool's purpose, return contents, and parameter format with no wasted words. The core function is front-loaded, and the parameter clarification is packed efficiently into parentheses.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with an output schema available, the description is largely complete: it defines the input format and summarizes the return payload. It could add explicit usage routing or edge-case behavior, but the low complexity and presence of an output schema make the current definition sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so thoroughly by specifying the email_id format ('folder:uid') and providing a concrete example ('INBOX:1'), which adds meaning far beyond the schema's bare string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('read'), a specific resource ('single email full content'), and clarifies the output composition ('plain text body + attachment metadata'). This distinguishes it from siblings like get_email_headers, get_attachments, and get_thread, which target headers, attachments, or thread context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when full content of a single email is needed—but gives no explicit guidance about when not to use it or which alternative to prefer. The sibling tools provide context, but the description itself does not name exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds valuable behavioral facts beyond the basic purpose: results are metadata-only, body is empty, and results are returned in server order rather than sorted. It does not mention pagination or limit behavior, but the core behavior is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, starting with the search criteria, then result behavior, then the routing note. Every clause adds distinct value and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers main search semantics and returns metadata, and the output schema exists to document return fields. However, with 0% parameter schema coverage and no annotations, the absence of folder semantics and date/query format details leaves meaningful gaps for an agent trying to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 parameter meaning. It maps query, sender, and date range to the likely parameters (query, from_email, since/until), but it does not explain the folder parameter, date string format, or query syntax. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches emails by keyword, sender, and date range, with a specific verb and resource. It also explicitly distinguishes itself from read_email by noting that results contain metadata only and the body is empty.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-not-to-use condition: if you need the email body, use read_email instead. This is a clear alternative and exclusion, making the usage boundary unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses key behavior: it only performs login verification, does not send email, and returns itemized results. It could mention failure behavior or side effects like authentication attempts, but the core transparency is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the primary purpose and includes the critical caveat that no email is sent. Every phrase adds value and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema already present, the description covers what the tool does, what it avoids doing, and what it returns. No additional context is needed for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to document. The description appropriately references the 'current configuration' as the implicit input source, which is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear action—testing the IMAP and SMTP connection using the current configuration—and explicitly states it does not send email. This distinguishes it from all sibling email operations like send_email, list_inbox, and configure_account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to validate the current email configuration before performing email operations, but it does not explicitly state when to use it versus alternatives such as configure_account or get_account_status. No direct exclusions or alternative routing are provided.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/pp123ys/email-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server