Skip to main content
Glama
mailpal-com

mailpal-mcp

Official
by mailpal-com
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

Server Quality Checklist

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

  • Latest release: v1.1.1

  • Disambiguation5/5

    The two tools are clearly distinct: one handles email, the other handles identity. There is no overlap or ambiguity between them.

    Naming Consistency2/5

    Both tool names are single-word product names, lacking any verb_noun pattern. They are not descriptive of actions, and there is no consistent naming convention for operations since all actions are hidden behind a generic 'operation' parameter.

    Tool Count2/5

    Only two tools for two domains (email and identity) is extremely thin. Each tool is a catch-all that requires further parameterization, making the count misleadingly low for the apparent scope.

    Completeness2/5

    The tools do not expose direct operations; they only serve as entry points to a readme. The actual functionality is not represented in the tool surface, leading to significant gaps for agents that cannot dynamically introspect.

  • Average 2/5 across 2 of 2 tools scored.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 1 commit in the last 12 weeks
    • No stable releases found
    • No critical vulnerability alerts
    • No high-severity vulnerability alerts
    • No code scanning findings
    • CI status not available

  • 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

  • Behavior1/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It fails to mention any side effects (e.g., mutations), authentication requirements, rate limits, or what happens with different operations. The phrase 'Hardware-anchored identity' is not elaborated, leaving the agent uninformed about critical behavioral aspects.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness3/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is short (30 words) but is not concise because it mixes a vague purpose with a meta-instruction. The front-loaded information about hardware-anchored identity is unclear. The structure is reasonable but could be improved by separating the gateway instruction from the stated purpose.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness1/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the tool's complexity as a gateway with dynamic operations, the description is severely incomplete. It provides no details about the response (output schema exists but is not referenced), no enumeration of possible operations, and no explanation of how 'params' are used. The agent cannot effectively select or invoke this tool based on the description alone.

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters2/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    Schema description coverage is 0%, so the description must compensate. It only mentions one specific operation value ('readme') and does not describe the 'params' object at all. The agent gains little semantic understanding beyond the basic structure. The URL (1id.com) provides some context but does not clarify parameter usage.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose2/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description states a high-level purpose ('Manage identity, devices, peer verification, and credentials') but lacks a specific verb+resource combination. It also introduces a meta-instruction about calling with operation='readme', creating confusion about what the tool actually does. The purpose is vague and not clearly distinguished from the sibling tool 'mailpal'.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines1/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No explicit guidance on when to use this tool vs alternatives. The instruction to call with operation='readme' suggests the tool itself is used to retrieve documentation, but this contradicts the stated purpose of managing identity. No exclusions or context are provided, leaving the agent without clear usage criteria.

    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 bears full responsibility for disclosing behavioral traits. It mentions hardware attestation but does not explain side effects, auth requirements, rate limits, or how to invoke different operations. The description is too brief to provide adequate transparency.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness3/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is very concise (two sentences) and front-loaded with the main purpose. However, it sacrifices necessary detail for conciseness, especially for a gateway tool with multiple operations. It is appropriately sized but lacks structure for parameter guidance.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness2/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the tool's complexity (gateway with sub-operations), 0% schema coverage, and no annotations, the description is incomplete. It does not explain how to perform the claimed email actions or what the output schema contains, forcing reliance on a meta-operation (readme).

    Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

    Parameters1/5

    Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

    Schema coverage is 0%, and the description only hints at using operation='readme'. It does not explain the purpose of the 'operation' parameter (list of values) or the 'params' parameter, leaving the agent with no semantic understanding of the parameters.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose4/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states the tool is for email operations (send, receive, manage) with hardware attestation, distinguishing it from the unrelated sibling 'oneid'. However, it doesn't specify which sub-operations correspond to these actions, relying on a readme operation for detail.

    Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

    Usage Guidelines2/5

    Does the description explain when to use this tool, when not to, or what alternatives exist?

    No guidance on when to use this tool vs alternatives, and no explicit when-to-use or when-not-to-use advice. The only hint is to call with operation='readme' for documentation, which is a usage instruction but not a guideline for selection.

    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

mcp-python MCP server

Copy to your README.md:

Score Badge

mcp-python MCP server

Copy to your README.md:

Latest Blog Posts

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/mailpal-com/mcp-python'

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