Skip to main content
Glama
Sign In

OneSimpleAPI

by com.onesimpleapi
OverviewDiscussionsAdmin

POST /api/email

api_post_email
Destructive

Validate email addresses, check deliverability, detect disposable emails, and more Uses the OneSimpleAPI API (https://onesimpleapi.com/docs), with the same permissions, credits and storage. Supply API parameters in query or body. This tool always uses POST; do not supply method. Outputs preserve HTTP status, headers and JSON/text/base64 body; redirects are returned without following them.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "api_post_email"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyNoAPI request body. Nested objects, arrays, HTML, base64 data and all API options retain their original meaning.
pathNo
filesNoMultipart uploads keyed by API field name (for example pdf). Supply file_name, base64 bytes and optional mime_type. Uploads use the existing API file validators.
queryNoURL query parameters. Sensitive API options must be in body as documented by the API.
headersNoAPI request headers such as Idempotency-Key, Range and If-None-Match. Authentication and transport headers are managed by the connection.
content_typeNoDefaults to application/json, or multipart/form-data when files are supplied.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.4/5.0
Behavior4/5

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

Beyond the annotations, it discloses real behavior: it consumes OneSimpleAPI credits and storage, it preserves HTTP status/headers and JSON/text/base64 bodies, and redirects are returned unfollowed rather than transparently resolved. That redirect and output-fidelity detail is exactly the kind of thing an agent cannot infer. It does not address the tension between the benign-sounding "validate" framing and the destructiveHint=true annotation, so it falls short of 5.

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 capability statement is front-loaded and earns its place, but the remainder is a run-on of generic wrapper boilerplate ("with the same permissions, credits and storage"), and the dangling "and more" adds vagueness rather than information. Nothing is badly misplaced, but several clauses could be trimmed or consolidated.

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?

For a 6-parameter tool with nested body/query/files objects and no output schema, the description compensates on the return side by stating that status, headers and body are preserved and redirects are not followed. What remains unstated is the credit cost per call and the exact shape of the deliverability result beyond the enum list in the schema.

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?

Schema description coverage is already 83%, so the schema documents email, output, files, headers and content_type well on its own. The description adds only the wrapper-level rule that parameters go in query or body and that no method field should be supplied, which is useful but thin. Baseline 3 is appropriate when the schema carries the parameter burden.

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 names a specific verb+resource combination ("Validate email addresses, check deliverability, detect disposable emails") that is immediately distinguishable from the sibling endpoints (PDF, QR code, screenshot, shortener, etc.). It stops short of the top score because "and more" leaves the exact capability surface fuzzy and no sibling is ever named.

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?

What guidance exists is invocation mechanics, not selection guidance: "Supply API parameters in query or body" and "This tool always uses POST; do not supply method." There is no statement of when this tool is appropriate versus other OneSimpleAPI endpoints, no prerequisites, and no exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All OneSimpleAPI toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources