Skip to main content
Glama
rowb53
by rowb53

oganvil-mcp

A minimal Model Context Protocol server for the oganvil OG image API — generate 1200×630 social preview images from a title and tag line, straight from your AI editor or agent.

Zero dependencies. Node 18+. Speaks MCP over stdio, so it works with Claude Desktop, Claude Code, Cursor, Windsurf, or any MCP-capable client.

Tools

Tool

Arguments

Returns

generate_og_image

title (required), tag, format (png|svg)

The 1200×630 image (PNG/SVG) plus a hosted render URL

get_quota

—

Current usage for the configured key (no quota consumed)

Identical renders (same title + tag + format) are served from cache and never billed twice.

Related MCP server: Opengraph io MCP

Install & run

# no install needed — run straight from source
node src/index.js

Claude Desktop / Claude Code / Cursor / Windsurf

Add to your MCP client config (claude_desktop_config.json, .cursor/mcp.json, …):

{
  "mcpServers": {
    "oganvil": {
      "command": "node",
      "args": ["/absolute/path/to/oganvil-mcp/src/index.js"],
      "env": {
        "OGANVIL_API_KEY": "oganvil-demo-key"
      }
    }
  }
}

oganvil-demo-key is a public free key: 10 renders/day per IP, no signup. For the permanent free tier (50 unique images/month, no card) grab a key at https://oganvil.rowu.workers.dev/signup.

Configuration

Env var

Default

Meaning

OGANVIL_API_KEY

oganvil-demo-key

Your API key (free key from /signup, or a paid key)

OGANVIL_API_URL

https://oganvil.rowu.workers.dev

API base URL

Example session

→ initialize
← {"serverInfo":{"name":"oganvil-mcp","version":"0.1.0"}}

→ tools/call generate_og_image {"title":"Ship faster","tag":"oganvil","format":"png"}
← image/png 1200x630 (28 KB) + hosted URL https://oganvil.rowu.workers.dev/api/render?title=Ship+faster&tag=oganvil

Verified output from this repo's source: PNG signature 89504e47, dimensions 1200 x 630, ~28 KB.

Also available over HTTP

If your client speaks remote MCP (Streamable HTTP), you don't need this package at all — the hosted server is at:

POST https://oganvil.rowu.workers.dev/mcp
Authorization: Bearer oganvil-demo-key

Two tools there: generate_og_image, get_quota.

REST API

GET https://oganvil.rowu.workers.dev/api/render?title=Hello&tag=World&format=png

Free tier: 50 unique images/month, no credit card. Paid: $5/mo (500 images) and $29/mo (5,000 images).

License

MIT

Available Tools

2 tools
generate_og_imageA

Generate a 1200x630 Open Graph (social preview) image from a title and optional tag line. Returns the hosted image URL and PNG/SVG bytes. Repeat identical renders are cached and not billed twice.

ParametersJSON Schema
NameRequiredDescriptionDefault
tagNoOptional subtitle / tag line
titleYesMain headline text for the card
formatNoOutput format (default png)

TDQS

A4/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 disclose meaningful traits: the tool returns both a hosted URL and PNG/SVG bytes, and identical renders are cached and not double-billed, which is real cost/idempotency context. It omits auth requirements, rate limits, or text-length constraints.

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?

Three short sentences, each carrying distinct information: what is produced, what is returned, and how repeat calls are billed. Front-loaded with the core action and dimensions.

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?

No output schema exists, so the description must cover returns, and it does (hosted image URL plus PNG/SVG bytes). For a simple three-parameter generation tool with no annotations this is nearly complete, with only auth and size-limit behavior left unstated.

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%, so the baseline is 3. The description restates title and tag line and hints at format via 'PNG/SVG bytes', but adds no syntax, length, or defaulting detail beyond what the schema already documents.

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 and resource with concrete dimensions: 'Generate a 1200x630 Open Graph (social preview) image from a title and optional tag line.' The only sibling, get_quota, is an unrelated quota utility, so there is no ambiguity to disambiguate.

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 description (social preview cards from a title), but there is no explicit when-to-use statement, no prerequisites, and no alternatives named. Nothing is misleading, but nothing routes the agent either.

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

get_quotaA

Show the current monthly unique-image usage for the configured oganvil API key (no quota consumed).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.9/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden, and it delivers a genuinely useful behavioral trait: '(no quota consumed)' tells the agent this call is safe to make without side effects. It does not describe the return shape, but that is a minor gap for a simple read.

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?

A single, tightly written sentence that front-loads the verb and resource and appends the safety note in parentheses. Every clause earns its place with no filler.

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 simple, no-parameter, non-destructive read with no output schema, the description covers what the tool reports and one important behavioral caveat. Only the exact return format is unstated, which is acceptable given the tool's low complexity.

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

Parameters4/5

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

The tool takes zero parameters, so the baseline is 4. There are no parameters for the description to add semantic meaning to, and nothing is left ambiguous for the caller.

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?

States a specific verb (Show) and resource (current monthly unique-image usage) scoped to the configured API key. It is clearly a read-only status check, which implicitly separates it from the sibling generate_og_image, though it never names the sibling explicitly.

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 — an informational check to run when you want to know quota/usage — but there is no explicit 'when to use this vs generate_og_image' statement or stated prerequisites. Adequate minimum-viable guidance for a zero-param status tool.

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. 2 tool updatesv0.1.0
    • First observedgenerate_og_image
    • First observedget_quota

TDQS

A4.1/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one generates an OG image, the other reports quota usage. There is no overlap or plausible confusion between generating an image and checking monthly usage.

Naming Consistency5/5

Both tool names use a consistent snake_case verb_noun pattern: generate_og_image and get_quota. The convention is predictable and readable.

Tool Count4/5

Two tools is slightly below the typical 3-15 range, but it fits this server's narrow scope of image generation plus quota inspection. Each tool earns its place, though the set feels minimal.

Completeness4/5

The core lifecycle is covered: generating an image and checking quota consumption. Minor gaps exist, such as managing or listing previously generated cached images, but they are not essential for the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers