read-no-evil-mcp

by thekie

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct action (list, get, send, delete, move) on distinct email resources (accounts, folders, emails). There is no overlap; even list_emails and get_email are clearly differentiated by listing summaries vs. getting full content.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern using snake_case (e.g., list_accounts, get_email, delete_email, move_email, send_email). The naming is predictable and harmonizes across the entire set.
Tool Count5/5
7 tools is well-scoped for an email server. It covers essential operations (list accounts, list folders, list emails, get email, send email, delete email, move email) without unnecessary redundancy or bloat.
Completeness4/5
The tool surface covers the core email lifecycle: discover accounts/folders, read, send, delete, and move emails. Minor gaps include the lack of mark-as-read/unread, reply, or forward operations, but these are non-critical for basic email handling.
Average 3.8/5 across 7 of 7 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on February 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It fails to explain whether deletion is irreversible, moves to trash, requires special permissions, or has any side effects. A destructive action needs significantly more behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short with a clear header and structured Args block. No wasted words, but the Args section could be integrated into the main sentence for even tighter prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and three required parameters, the description omits important context: it does not mention the return value (output schema exists but is unaddressed), error conditions, idempotency, or prerequisites. A deletion tool should disclose the outcome or confirmation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the Args section adds meaning by naming what each parameter represents and giving an example for account (e.g., 'work', 'personal'). However, it does not provide additional constraints, formats, or range information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Delete an email by UID,' using a specific verb (delete) and resource (email) with the method (by UID). This clearly distinguishes it from sibling tools like get_email, list_emails, move_email, and 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as whether deletion is permanent or if there is a trash/purge workflow. It only states the action without any contextual cues or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It outlines parameters and defaults but does not disclose side effects (none expected for a read operation), error behavior, rate limits, or any constraints beyond param types. The fact that it returns 'summaries' rather than full email content is noted but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact, well-structured docstring listing parameters after a clear one-line purpose. Every sentence is functional and there is no redundancy. It could be slightly improved by grouping related parameters or adding a brief usage example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description does not need to explain return values. However, it omits any mention of pagination behavior (despite having offset and limit) and does not clarify what constitutes a 'summary'. For a tool with 6 parameters and no nested objects, this is adequate but slightly lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains each of the 6 parameters with brief meaning and defaults (e.g., 'folder: Folder to list emails from (default: INBOX)'). This adds valuable context beyond the raw schema types, though it does not describe the output format or parameter constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List email summaries from a folder', specifying the verb 'list' and resource 'email summaries'. The context of sibling tools like get_email and send_email helps distinguish it, though the meaning of 'summaries' is not elaborated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_email for a single email or list_folders for folder hierarchy. The description lacks context about typical use cases 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?
No annotations are provided, so the description carries full behavioral disclosure burden. The description states it returns 'all available email folders/mailboxes' and requires an account parameter, but does not disclose whether this is a read-only operation, any restrictions on which accounts work, or the structure of the response (e.g., hierarchical vs flat).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a one-liner purpose and a simple parameter explanation. Every word earns its place and there is no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (1 required parameter, no nested objects) and there is an output schema (though not shown in the input), the description is mostly complete. However, it does not clarify the relationship to siblings like list_accounts (perhaps needed first) or whether the output differs per account. Slight gaps in guidance on order of operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the baseline is lower and the description must compensate. The description clearly documents the single parameter 'account', explains its purpose as 'Account ID to use', and provides examples like 'work' or 'personal'. This adds meaningful context beyond the bare schema with only type 'string'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that it lists all available email folders/mailboxes, which is a clear verb+resource combination. It distinguishes this tool from siblings like list_emails and list_accounts by implying it returns folder structure rather than emails or accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the required account parameter with examples, which gives context for when to use it (with a specific account). However, it does not explicitly state when to use this tool versus alternatives like list_accounts (to get account IDs) or when it should be used before listing emails within a folder.
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 for behavioral disclosure. It only describes parameters and does not mention side effects, authentication requirements, rate limits, or what happens on success/failure. For a tool that sends data, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-sentence summary, followed by a structured parameter list. While it is relatively long due to detailed parameter docs, the structure is clear and each sentence serves a purpose. A minor improvement would be to shorten the attachment explanation, but it's still efficient for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, attachments, optional fields), the description covers parameter semantics well. It does not explain return values, but an output schema exists (not shown) which likely handles that. However, it lacks behavioral context like error handling or size limits, which would help an agent fully understand invocation risks. Overall, it is sufficient for basic selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, meaning the schema itself lacks descriptions for top-level parameters. The description compensates thoroughly by explaining each parameter (account, to, subject, body, cc, reply_to, attachments) and the attachment object structure, including required fields and defaults. This adds substantial value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Send an email with optional attachments,' which clearly states the verb (send) and resource (email). It distinguishes itself from sibling tools like delete_email, get_email, and list_accounts by focusing on sending rather than retrieving or deleting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs. alternatives, such as not to use it for reading emails or when to prefer list_emails. It provides no when-not-to-use guidance, leaving the agent to infer from sibling names. This is adequate but not proactive.
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 full burden. It mentions the action ('move') but does not disclose behavioral traits such as whether the move is irreversible, whether it updates flags, or whether it requires special permissions. The description is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single purpose sentence and a structured args list. Every sentence provides necessary information without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which likely documents return values), the description need not explain return behavior. It covers the essential parameters and action. Minor gap: no mention of what happens if the target folder does not exist, but overall complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must document parameters. It does so by listing all four parameters with brief, clear explanations (e.g., account: 'Account ID to use (e.g., "work", "personal")'). This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Move an email to a target folder' with the specific verb 'move' and resource 'email'. This directly distinguishes it from siblings like delete_email, get_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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to move emails between folders) but provides no explicit guidance on when not to use it or alternative tools. However, the sibling list and clear purpose help reduce ambiguity.
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 provided, so the description must convey behavior. The description is explicit about parameters but does not detail permissions requirements, output format, or side effects (e.g., whether it marks the email as read). However, it clearly indicates a read operation, which is inferred from 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three lines plus an Args section, all front-loaded. No wasted words; every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is an output schema (not shown but present), the description doesn't need to explain return values. It covers purpose, parameters, and usage context adequately. A small gap is the lack of explanation about what 'full email content' includes (e.g., attachments, headers).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 0% of parameter descriptions, but the description fully defines each parameter (account, folder, uid) with examples and context. This adds significant meaning beyond the bare schema, which only lists names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full email content using a UID, specifying the verb 'Get' and the resource 'email content'. This distinguishes it from siblings like 'list_emails' (which lists metadata) and 'delete_email' (which removes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you have a specific UID and need full email content, contrasting with 'list_emails' for summaries. It does not explicitly state when not to use it (e.g., for email metadata only) or mention alternatives, but the context is clear given sibling tool names.
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 provided, so description carries full burden. It describes the read-only nature and return format, but does not disclose authorization needs, error conditions, or other behavioral details, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with the core action first, followed by usage guidance and return format. No extraneous content; highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and a simple list operation, the description fully covers purpose, usage context, and return value. No additional information needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description adds no param info, but that is acceptable since schema coverage is trivially 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'List' and resource 'configured email account IDs'. Differentiates from sibling tools which operate on emails and folders, not accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use this tool before calling other email tools like list_emails, get_email, or list_folders, providing clear context for when it is appropriate.
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:

[![read-no-evil-mcp MCP server](https://glama.ai/mcp/servers/thekie/read-no-evil-mcp/badges/card.svg)](https://glama.ai/mcp/servers/thekie/read-no-evil-mcp)

Score Badge

Copy to your README.md:

[![read-no-evil-mcp MCP server](https://glama.ai/mcp/servers/thekie/read-no-evil-mcp/badges/score.svg)](https://glama.ai/mcp/servers/thekie/read-no-evil-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/thekie/read-no-evil-mcp'

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