-
My MCP Serv
Server Details
Non functional server (yet)
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
- Status
- Unhealthy
- Uptime
- 4.0% over 78 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- –
TDQS
A4.1/5.0
Scored across 1 tool
Disambiguation5/5
With a single tool there is no possibility of confusion or overlap. The tool's purpose is unambiguous: send an email via the Resend API.
Naming Consistency5/5
The lone tool follows a clear verb_noun snake_case convention (send_email). There is no inconsistency because there is nothing to compare against.
Tool Count3/5
One tool is thin even for a narrowly scoped email-sending server. It works for the stated purpose but offers no room for supporting operations.
Completeness2/5
Only a send operation exists; there is no way to check delivery status, list sent messages, manage templates/contacts, or handle attachments or replies. The surface is severely limited for an email integration.
Available Tools
1 toolsend_emailAInspect
Send an email via Resend API.
Args: sender_email: Sender email address (must be verified in Resend) to_emails: List of recipient email addresses subject: Email subject line text_content: Plain text content (required if html_content not provided) html_content: HTML content (required if text_content not provided)
Returns: API response with email ID on success
| Name | Required | Description | Default |
|---|---|---|---|
| subject | Yes | ||
| to_emails | Yes | ||
| html_content | No | ||
| sender_email | Yes | ||
| text_content | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningful work: it discloses the verified-sender prerequisite and the text_content/html_content either-or requirement, neither of which is encoded in the schema. It omits rate limits, error behavior, and whether sends are live, so it is solid but not complete.
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?
Front-loaded with the one-line purpose, then a tight Args block where every line carries unique parameter meaning. No filler, no repetition of the name or obvious facts.
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?
An output schema exists, so the brief returns line is sufficient and the description needn't explain response structure. Parameter coverage is complete; only failure modes and delivery guarantees are absent, which are minor for a straightforward send tool.
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?
Schema description coverage is 0%, so the description must compensate, and it documents all five parameters with their meaning and role. It goes further by stating the conditional dependency between text_content and html_content, which the schema's nullable defaults do not express.
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?
States a specific verb (send) and resource (email) plus the delivery mechanism (Resend API) in the first line, which is enough for an agent to identify the tool unambiguously. There are no siblings to differentiate from, so nothing further is required.
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?
Usage is implied by the tool's obvious purpose, and the description adds one real prerequisite ('sender_email must be verified in Resend'), but it never states when to prefer this tool, what happens on failure, or any exclusions. Adequate but with clear gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- First observed
send_email
Related MCP Connectors
Work in progress (for now)
Related MCP Servers
- -
- AlicenseNot gradedqualityBmaintenanceThis server is to precess files for LNR.3MIT
- AlicenseNot gradedqualityDmaintenanceAn archived, unsafe MCP server with critical security vulnerabilities, classified as a pump and dump operation. Do not use in production.5 npm2ISC
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd
Glama MCP Gateway
Add one secure layer between your agents and this server.