Opengraph io MCP

exportImageAsset

DestructiveIdempotent

Export a generated image asset using its session and asset ID to get base64 data plus format, dimensions, and size metadata; optionally save it to disk when running locally.

Instructions

Export a generated image asset by session and asset ID.

Returns the image inline as base64 along with metadata (format, dimensions, size).

When running locally (stdio transport), you can optionally provide a destinationPath to save the image to disk. Files are only ever written inside one export folder (~/Downloads/opengraph-mcp, or MCP_EXPORT_DIR); pass a file name or a path inside it. SVG is returned as a file only, never inline, because it can carry script.

USAGE: After generating an image with generateImage, use the sessionId and assetId to export: exportImageAsset(sessionId="...", assetId="...")

To save to disk (local/stdio only): exportImageAsset(sessionId="...", assetId="...", destinationPath="logo.png")

Input Schema

Name	Required	Description
`assetId`	Yes	The asset UUID to export
`sessionId`	Yes	The session UUID containing the asset
`destinationPath`	No	Optional file name or path inside the export folder (~/Downloads/opengraph-mcp, or MCP_EXPORT_DIR). Only works when the server is running locally (stdio transport).

Output Schema

Name	Required	Description	Default
`path`	No
`size`	No
`error`	No
`format`	No
`success`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv3.2.1Oct 23, 2026

changedInput schema / properties / destinationPath / description

Previous value: -"Optional absolute path to save the image to disk. Only works when the server is running locally (stdio transport)."New value: +"Optional file name or path inside the export folder (~/Downloads/opengraph-mcp, or MCP_EXPORT_DIR). Only works when the server is running locally (stdio transport)."

addedInput schema / properties / destinationPath / maxLength
```
Added value: +1024
```

Changed1 schema field changedv1.3.6Jul 6, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "error": {
+      "type": "string"
+    },
+    "format": {
+      "type": "string"
+    },
+    "path": {
+      "type": "string"
+    },
+    "size": {
+      "type": "number"
+    },
+    "success": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "success"
+  ],
+  "type": "object"
+}

First observedv1.3.5Feb 26, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well past the annotations by disclosing the return shape (inline base64 plus format, dimensions, size), the file-write sandbox (~/Downloads/opengraph-mcp or MCP_EXPORT_DIR, name or path inside it only), and the security-driven exception that SVG is never returned inline because it can carry script.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose, then returns, then constraints, then usage examples. Slight redundancy: the destinationPath folder rule is restated almost verbatim in both the paragraph and the usage block.

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?

An output schema exists so return values needn't be spelled out, and annotations plus description cover safety and side effects. It omits failure modes (expired session, unknown assetId) that would help an agent recover from errors.

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?

Schema coverage is 100%, so a baseline 3 applies, but the description adds real meaning: sessionId/assetId come from a prior generateImage call, and destinationPath is transport-conditional and confined to the export folder.

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 ("Export a generated image asset by session and asset ID") and ties itself to the generateImage lifecycle, so an agent can distinguish it from inspectImageSession or iterateImage without opening a schema.

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?

Gives an explicit prerequisite ("After generating an image with generateImage") plus concrete call examples, and states the local/stdio condition for destinationPath. It never names an alternative tool for inspecting or listing assets, so the when-not guidance is incomplete.

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

Deploy Server