Loading ToolBench

Reading the current corpus…

drin-mcp MCP server · C · ToolBench

← Browse

drin-mcp

github.com/ATOM00blue/drin-mcp

The complete email loop for AI agents: send, receive, parse, thread, reply, approve, and manage Drin with 54 MCP tools.

2026-07-28+STDIO1 tools

64/100

Definition Quality88

Protocol Readiness35

Supportability42

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence

Current-spec patterns detected

Summary

Single tool 'send_email' has a well-structured JSON Schema with 13 parameters, all typed and described. Naming follows verb_noun convention (send_email). Description is clear and actionable (98 chars). Schema includes proper type unions (string|array for addresses), format hints (ISO 8601 for scheduledAt), and optional/required field distinction. However, the server exposes only 1 of 54 claimed tools in the source code provided, the package.json claims '54 MCP tools' but only send_email is visible. This is a critical gap: either the other 53 tools are missing from the repo, or the evaluation is incomplete. Assuming the visible tool is representative, the quality is solid but incomplete.

Tools (1)

send_emailwriteauthsource verified88/100

Send a transactional email. Provide `html` and/or `text`, or render a saved template with `templateId` + `data`. Addresses accept "Name <email>" or bare "email".

Issues (5)

CRITICALtool ↗

Only 1 of 54 claimed tools visible in source. Package.json declares '54 MCP tools' but src/tools.ts shows only send_email definition. Remaining 53 tools are either missing, not yet implemented, or not included in the provided code sample.

all

HIGHtool ↗

send_email lacks output schema documentation. Tool description does not specify what fields are returned (e.g., messageId, status, scheduledTime). LLMs cannot plan downstream calls without knowing response structure.

send_email

HIGHrecovery-guide ↗

No error handling guidance in send_email description. Does not explain what happens on invalid 'from' domain, malformed addresses, or template not found. LLMs need recovery hints (e.g., 'If template not found, call list_templates first').

send_email

MEDIUMtool-description ↗

Parameter 'sender' is optional and overrides server default, but no description explains when/why to use it. Guidance like 'Required for account-wide API keys; omit for product-scoped keys' would clarify intent.

Recommendations

Document send_email output schema: specify fields like messageId (string), status (enum: queued|sending|sent|failed), scheduledTime (ISO 8601), and any error details. This enables LLMs to extract IDs for tracking or retry logic.
Add error recovery guidance to send_email description: 'If template not found, call list_templates(). If 'from' domain unverified, check verified_domains resource. If rate limited, retry after 60s.'
Clarify 'sender' parameter: 'Required only when using account-wide API keys to specify which product/sender to use. Omit if using product-scoped keys.' This prevents confusion and unnecessary parameter passing.
Document idempotency semantics: 'Provide idempotencyKey to safely retry failed sends. Same key + same parameters = same messageId returned; duplicate sends prevented.' This guides agent retry logic.
Implement and expose remaining 53 tools claimed in package.json. If not yet built, update package.json description to reflect current scope (e.g., 'Email sending via MCP' instead of '54 MCP tools').

Score history

Overall score trend

First recorded score · v2 rubric

64/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	C	64	2026-07-28+	v2