oganvil-mcp
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@oganvil-mcpCreate an OG image titled "Weekly Digest" with tag "Product News""
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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 |
|
| The 1200×630 image (PNG/SVG) plus a hosted render URL |
| — | 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.jsClaude 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 |
|
| Your API key (free key from |
|
| 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=oganvilVerified 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-keyTwo tools there: generate_og_image, get_quota.
REST API
GET https://oganvil.rowu.workers.dev/api/render?title=Hello&tag=World&format=pngFree tier: 50 unique images/month, no credit card. Paid: $5/mo (500 images) and $29/mo (5,000 images).
License
MIT
Available Tools
2 toolsgenerate_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.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Optional subtitle / tag line | |
| title | Yes | Main headline text for the card | |
| format | No | Output format (default png) |
TDQS
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.
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.
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.
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.
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.
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).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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.
2 tool updates
v0.1.0- First observed
generate_og_image - First observed
get_quota
TDQS
Scored across 2 tools
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.
Both tool names use a consistent snake_case verb_noun pattern: generate_og_image and get_quota. The convention is predictable and readable.
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.
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
Related MCP Connectors
Generates 1200x630 OG social preview images (PNG/SVG). Tools: generate_og_image, get_quota.
Generates 1200x630 OG social preview images (PNG/SVG). Tools: generate_og_image, get_quota.
Pay-as-you-go Open Graph image API. Renders 1200x630 PNGs for agents. Credits never expire.
Generate on-brand images from your AI agent: design, edit, and render templates over MCP.
Related MCP Servers
- AlicenseAqualityCmaintenanceGenerate production-ready images from text prompts. AI-powered design API with 50+ templates for social posts, banners, OG images, and more.89 npmMIT
- AlicenseAqualityBmaintenanceMCP server for the OpenGraph.io API -- extract OG metadata, capture screenshots, scrape pages, query sites with AI, and generate branded images with iterative refinement.28310 npm2ISC
- AlicenseNot gradedqualityDmaintenancePaste a URL to see exactly how it renders as a social card on Twitter, LinkedIn, Facebook, and Slack. Generate custom OG images from templates.MIT

ogimage-mcpofficial
FlicenseAqualityDmaintenanceGenerates beautiful Open Graph images directly from Claude Desktop using ogimage.art, supporting templates, sizes, and license keys.3-