Skip to main content
Glama
seanfenlon

ABOVO MCP Server

by seanfenlon
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

ABOVO MCP Server

Publish any content to a permanent public web page by sending an email.

No API key. No signup. No authentication required. SMTP is the API.

US Patent No. 10,404,634 — Abovo42 Corporation — Founder: Sean P. Fenlon

How It Works

Send any email to POST@abovo.co and it instantly becomes a public web page. ABOVO replies with your permanent URL within seconds.

Action

Email To

Publish to personal page

POST@abovo.co

Post to a group

[groupname]@abovo.co

URL Patterns

URL

Description

https://www.abovo.co/{sender-email}

All posts by that sender

https://www.abovo.co/{sender-email}/{post-id}

Specific post

https://{groupname}.abovo.co

Group page (e.g. jazz.abovo.co)

Group Moderation

When you send the first email to a new [groupname]@abovo.co, ABOVO sends you a confirmation email. Click "I accept" to activate the group — you become the moderator. Until confirmed, the group does not appear on ABOVO.co.

Related MCP server: DOOMSCROLLR MCP Server

MCP Tools

publish_to_web

Publishes content to ABOVO.co by sending an email through a single, server-configured SMTP identity (ABOVO_SMTP_USER). The tool does not publish as the individual end-user or caller — every post originates from the one identity the server is configured with.

Parameters:

  • subject (required) — page title

  • body (required) — page content (plain text or HTML)

  • format (optional, default html) — text or html

  • group (optional) — post to a group ([group]@abovo.co) instead of the personal page

Note: This tool does not accept file attachments. The input schema is limited to subject, body, format, and group.

Returns: A confirmation that the email was sent, plus a link to the sender's ABOVO.co page (https://www.abovo.co/{sender}/), which lists all of that sender's posts. It does not return the exact URL of the newly created post — ABOVO.co emails that permanent per-post URL to the sending address separately, after processing. See Experimental — known limitations.

get_abovo_info

Returns information about ABOVO.co capabilities, URL formats, groups, or use cases.

Query values: capabilities, url_format, groups, use_cases, about

Installation & Usage (local stdio)

This server runs locally over stdio — there is no hosted or remote endpoint. Both installation methods below download from this repository's Releases page. Neither one requires an account or a signup anywhere.

Option 1 — Claude Desktop bundle (recommended)

Download abovo-mcp-server-1.1.1.mcpb from the latest release and double-click it.

Claude Desktop opens an install dialog that asks for your email address and your password (or, for Gmail, an App Password). The password is handed to your operating system's credential store — macOS Keychain, Windows Credential Manager, or the Linux Secret Service — and is never written into a configuration file in plain text.

There is nothing else to configure and no dependency install step: the bundle carries a single self-contained Node build.

Option 2 — command line, straight from the release asset

For any MCP client you configure by hand, install the tarball attached to the same release:

npm install -g https://github.com/seanfenlon/abovo-mcp-server/releases/download/v1.1.1/seanfenlon-abovo-mcp-server-1.1.1.tgz

This is a plain URL install — npm fetches the file over HTTPS and never contacts the npm registry, so no npm account or login is involved. It exposes the abovo-mcp-server command, a stdio MCP server:

Claude Desktop (claude_desktop_config.json)

{
  "mcpServers": {
    "abovo": {
      "command": "abovo-mcp-server",
      "env": {
        "ABOVO_SMTP_USER": "you@example.com",
        "ABOVO_SMTP_PASS": "your-app-password"
      }
    }
  }
}

If the client reports that the command was not found, it is not inheriting your shell's PATH — a common situation for GUI applications on macOS. Run which abovo-mcp-server (where abovo-mcp-server on Windows) and put that absolute path in "command" instead.

Environment variables — the bundle installer collects these for you through its dialog; set them yourself only for the command-line install:

Variable

Required

Description

ABOVO_SMTP_USER

Yes

SMTP username / email address

ABOVO_SMTP_PASS

Yes

SMTP password or app password

ABOVO_SMTP_HOST

No

SMTP hostname (default: smtp.gmail.com)

ABOVO_SMTP_PORT

No

SMTP port (default: 587)

ABOVO_SENDER_EMAIL

No

From address (defaults to ABOVO_SMTP_USER)

ABOVO_TELEMETRY_FILE

No

Where the telemetry JSONL file is written (see Telemetry below)

ABOVO_TELEMETRY_DISABLED

No

Set to 1 to disable telemetry completely

Telemetry

This server records lightweight local telemetry, and it is on by default. For each lifecycle or publish event it prints one line to standard error and appends the same line to a JSONL file.

It records coarse metadata only: the event name, a timestamp, the server version, the transport, the content format, and whether the target was a personal page or a group. It never records subjects, message bodies, email addresses, or credentials.

Where the file goes:

  • Local stdio install (either the bundle or the tarball): the operating system's temporary directory (abovo-mcp-telemetry.jsonl).

  • Otherwise: a logs/ folder relative to the working directory.

You can point it elsewhere with the ABOVO_TELEMETRY_FILE environment variable, or silence it completely by setting ABOVO_TELEMETRY_DISABLED to 1.

Experimental — known limitations

The publish_to_web MCP tool is experimental. Current known limitations:

  • No per-caller identity. All posts are sent from a single, server-configured SMTP identity (ABOVO_SMTP_USER). The tool cannot publish as the individual end-user or caller.

  • No exact-URL return. The tool returns a link to the sender's general ABOVO.co page, not the permanent URL of the specific new post. ABOVO.co emails that per-post URL to the sending address separately.

  • No attachments. The input schema accepts only subject, body, format, and group. File attachments (images, PDFs, other files) cannot be sent through this tool.

  • No idempotency. Repeated calls with identical arguments send repeated emails and create duplicate posts. There is no deduplication or idempotency key.

Patent Notice

This project relates to U.S. Patent No. 10,404,634 B2. The open-source license granted for this repository (the MIT License) applies to the copyright in this software only. That license does not, by itself, grant any license or other rights under U.S. Patent No. 10,404,634 B2 beyond those necessary to run this software as provided. No patent license is granted by implication, estoppel, or otherwise, except as expressly set out in a separate written agreement.

Links

Available Tools

2 tools
get_abovo_infoA
Read-onlyIdempotent

Get information about ABOVO.co capabilities, URL formats, groups, or use cases.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesWhat information to retrieve about ABOVO.co

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'Get information' is consistent with these. However, the description adds no additional behavioral context beyond the annotations, such as return format, pagination, authentication needs, or rate limits.

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 one sentence, directly front-loaded, and free of filler words. It efficiently communicates the tool's purpose without redundancy.

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?

This is a simple, read-only informational tool with one parameter, a complete enum in the schema, and strong annotations. The description covers the main query categories, though it omits the 'about' enum value explicitly. No output schema exists, but the description is adequate for the tool's simplicity.

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?

The input schema fully documents the single 'query' parameter with an enum and a description, giving 100% schema coverage. The tool description lists most of the enum values but does not add significant extra meaning beyond what the schema already provides.

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 uses a specific verb ('Get information') and clearly identifies the resource (ABOVO.co) and the scope of data (capabilities, URL formats, groups, use cases). It distinguishes itself from the sibling tool 'publish_to_web' by focusing on information retrieval rather than publishing.

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 explicit guidance on when to use this tool versus alternatives, nor does it state any exclusions or prerequisites. It simply describes what the tool does, leaving the agent to infer usage context from the tool name and sibling tool.

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

publish_to_webA

Publish content to a public web page on ABOVO.co by emailing it through a single, server-configured SMTP identity. Accepts a subject, body, format (text or html), and an optional group. Does NOT support file attachments — the input schema is limited to subject/body/format/group. Returns a confirmation and a link to the sender's ABOVO.co page; it does NOT return the exact URL of the new post (ABOVO.co emails that permanent URL to the sending address separately). Not idempotent: repeated calls create duplicate posts.

ParametersJSON Schema
NameRequiredDescriptionDefault
bodyYesContent to publish. Can be plain text or HTML.
groupNoGroup name. If provided, posts to [group]@abovo.co instead. Letters, digits and hyphens only.
formatNoContent formathtml
subjectYesSubject line / title of the web page

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint false, idempotentHint false), the description explains the non-idempotent behavior in concrete terms ('repeated calls create duplicate posts'), reveals that publishing happens via a single configured SMTP identity, and discloses the unusual return behavior (confirmation plus a link to the sender's page, not the new post URL). This is rich, actionable context.

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 compact yet information-dense: one sentence for purpose, one for input list, and one each for exclusions, return behavior, and idempotency. Every sentence adds value, and the structure is logical and scannable.

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 there is no output schema, the description properly covers return values (confirmation, sender page link, absence of exact URL) and side effects (duplicate posts on repeat). It also notes the mechanism (email) and the full input scope, making the tool safe and predictable for an agent without needing additional context.

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 100%, with each parameter already described. The description adds minor context by listing the parameters (subject, body, format, group) and mentioning that attachments are not supported, but it does not meaningfully extend the schema's parameter meanings. Baseline of 3 is appropriate.

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's verb and resource: "Publish content to a public web page on ABOVO.co" via a specific SMTP identity. It is unambiguously distinct from the sibling get_abovo_info, which is an info/read tool.

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 gives explicit usage cautions: no file attachments are supported, and repeated calls create duplicate posts. It also notes that the exact post URL is not returned (it is emailed separately), helping an agent decide whether this tool meets the need. It does not name an alternative tool, but the only sibling is clearly for reading info, so context is sufficient.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

The two tools have clearly distinct purposes: one publishes content, the other provides information about the service. There is no overlap or ambiguity between them.

Naming Consistency4/5

Both tools follow a verb-first pattern with underscores (publish_to_web, get_abovo_info), though one includes a preposition and the other doesn't. The style is consistent enough to be predictable.

Tool Count3/5

With only two tools, the server feels thin for a general-purpose MCP server. The count is borderline, but the tools are both essential to the server's stated purpose.

Completeness3/5

The server provides a publish capability but no way to read, update, or delete published posts. The info tool helps users understand the service, but the core workflow lacks lifecycle coverage. The design seems intentional since URLs are emailed separately, but from an MCP perspective, the surface is incomplete.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

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/seanfenlon/abovo-mcp-server'

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