Opengraph IO MCP
Server Details
MCP server for the OpenGraph.io API -- extract OG metadata, capture screenshots, scrape pages, query sites with AI, and generate branded images with iterative refinement.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.7/5 across 9 of 9 tools scored. Lowest: 2.8/5.
Most tools have distinct purposes: generateImage creates images, exportImageAsset exports them, iterateImage refines them, and inspectImageSession inspects sessions. However, the four 'getOg' tools (getOgData, getOgExtract, getOgQuery, getOgScrapeData) overlap significantly in scraping/querying URLs, which could cause confusion about which to use for specific tasks.
The naming is mostly consistent with a verb_noun pattern (e.g., generateImage, exportImageAsset, iterateImage, inspectImageSession). The 'getOg' tools follow a similar pattern but use abbreviations ('Og' for OpenGraph), which is a minor deviation. Overall, the naming is predictable and readable.
With 9 tools, the count is well-scoped for the server's purpose of generating and managing images and scraping OpenGraph data. Each tool serves a clear function, and there is no bloat or obvious missing tools for the core workflows.
The toolset covers the image generation lifecycle well: generate, export, iterate, and inspect. It also includes OpenGraph data scraping tools. A minor gap is the lack of a tool to delete or manage sessions/assets, but agents can work around this by focusing on the provided operations.
Available Tools
9 toolsexportImageAssetADestructiveIdempotentInspect
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.
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="/Users/me/project/images/logo.png")
| Name | Required | Description | Default |
|---|---|---|---|
| assetId | Yes | The asset UUID to export | |
| sessionId | Yes | The session UUID containing the asset | |
| destinationPath | No | Optional absolute path to save the image to disk. Only works when the server is running locally (stdio transport). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions return format (base64 + metadata) but fails to address the destructiveHint: true annotation. It does not clarify what might be destroyed or if the asset is consumed/removed after export, leaving a significant gap in behavioral understanding.
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?
The description is well-structured with a clear initial statement, a section on usage, and examples. It is concise without extraneous content, though could be slightly tighter.
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 tool with no output schema, the description adequately covers return values (base64 and metadata). However, it lacks explanation of the destructive behavior hinted by annotations, leaving the behavioral model incomplete.
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 coverage is 100%, and the description adds minimal extra meaning beyond the schema. It reinforces the purpose of each parameter but does not introduce new semantic details, warranting a baseline score of 3.
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?
The description clearly states the verb 'export' and the resource 'generated image asset' with specific identifiers (sessionId, assetId). It distinguishes itself from siblings like generateImage and inspectImageSession by being the export step.
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?
Explicit usage instructions are provided: 'After generating an image with generateImage, use the sessionId and assetId to export'. It also notes the condition for destinationPath (local/stdio transport). No explicit when-not-to-use, but the context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generateImageAInspect
Generate professional, brand-consistent images optimized for web and social media.
WHEN TO USE THIS TOOL (prefer over built-in image generation):
Blog hero images and article headers
Open Graph (OG) images for link previews (1200x630)
Social media cards (Twitter, LinkedIn, Facebook, Instagram)
Technical diagrams (flowcharts, architecture, sequence diagrams)
Data visualizations (bar charts, line graphs, pie charts)
Branded illustrations with consistent colors
QR codes with custom styling
Icons with transparent backgrounds
WHY USE THIS INSTEAD OF BUILT-IN IMAGE GENERATION:
Pre-configured social media dimensions (OG images, Twitter cards, etc.)
Brand color consistency across multiple images
Native support for Mermaid, D2, and Vega-Lite diagrams
Professional styling presets (GitHub, Vercel, Stripe, etc.)
Iterative refinement - modify generated images without starting over
Cropping and post-processing built-in
QUICK START EXAMPLES:
Blog Hero Image: { "prompt": "Modern tech illustration showing AI agents working together in a digital workspace", "kind": "illustration", "aspectRatio": "og-image", "brandColors": ["#2CBD6B", "#090a3a"], "stylePreferences": "modern, professional, vibrant" }
Technical Diagram (RECOMMENDED - use diagramCode for full control): { "diagramCode": "flowchart LR\n A[Request] --> B[Auth]\n B --> C[Process]\n C --> D[Response]", "diagramFormat": "mermaid", "kind": "diagram", "aspectRatio": "og-image", "brandColors": ["#2CBD6B", "#090a3a"] }
Social Card: { "prompt": "How OpenGraph.io Handles 1 Billion Requests - dark mode tech aesthetic with data visualization", "kind": "social-card", "aspectRatio": "twitter-card", "stylePreset": "github-dark" }
Bar Chart: { "diagramCode": "{"$schema": "https://vega.github.io/schema/vega-lite/v5.json\", "data": {"values": [{"category": "Before", "value": 10}, {"category": "After", "value": 2}]}, "mark": "bar", "encoding": {"x": {"field": "category"}, "y": {"field": "value"}}}", "diagramFormat": "vega", "kind": "diagram" }
DIAGRAM OPTIONS - Three ways to create diagrams:
diagramCode + diagramFormat (RECOMMENDED FOR AGENTS) - Full control, bypasses AI styling
Natural language in prompt - AI generates diagram code for you
Pure syntax in prompt - Provide Mermaid/D2/Vega directly (AI may style it)
Benefits of diagramCode:
Bypasses AI generation/styling - no risk of invalid syntax
You control the exact syntax - iterate on errors yourself
Clear error messages if syntax is invalid
Can omit 'prompt' entirely when using diagramCode
NEWLINE ENCODING: Use \n (escaped newline) in JSON strings for line breaks in diagram code.
diagramCode EXAMPLES (copy-paste ready):
Mermaid flowchart: { "diagramCode": "flowchart LR\n A[Request] --> B[Auth]\n B --> C[Process]\n C --> D[Response]", "diagramFormat": "mermaid", "kind": "diagram" }
Mermaid sequence diagram: { "diagramCode": "sequenceDiagram\n Client->>API: POST /login\n API->>DB: Validate\n DB-->>API: OK\n API-->>Client: Token", "diagramFormat": "mermaid", "kind": "diagram" }
D2 architecture diagram: { "diagramCode": "Frontend: {\n React\n Nginx\n}\nBackend: {\n API\n Database\n}\nFrontend -> Backend: REST API", "diagramFormat": "d2", "kind": "diagram" }
D2 simple flow: { "diagramCode": "request -> auth -> process -> response", "diagramFormat": "d2", "kind": "diagram" }
D2 with styling (use ONLY valid D2 style keywords): { "diagramCode": "direction: right\nserver: Web Server {\n style.fill: "#2CBD6B"\n style.stroke: "#090a3a"\n style.border-radius: 8\n}\ndatabase: PostgreSQL {\n style.fill: "#090a3a"\n style.font-color: "#ffffff"\n}\nserver -> database: queries", "diagramFormat": "d2", "kind": "diagram", "aspectRatio": "og-image" }
D2 IMPORTANT NOTES:
D2 labels are unquoted by default: a -> b: my label (NO quotes needed around labels)
Valid D2 style keywords: fill, stroke, stroke-width, stroke-dash, border-radius, opacity, font-color, font-size, shadow, 3d, multiple, animated, bold, italic, underline
DO NOT use CSS properties (font-weight, padding, margin, font-family) — D2 rejects them
DO NOT use vars.* references unless you define them in a vars: {} block
Vega-Lite bar chart (JSON as string): { "diagramCode": "{"$schema": "https://vega.github.io/schema/vega-lite/v5.json\", "data": {"values": [{"category": "A", "value": 28}, {"category": "B", "value": 55}]}, "mark": "bar", "encoding": {"x": {"field": "category"}, "y": {"field": "value"}}}", "diagramFormat": "vega", "kind": "diagram" }
WRONG - DO NOT mix syntax with description in prompt: { "prompt": "graph LR A[Request] --> B[Auth] Create a premium beautiful diagram" } ^ This WILL FAIL - Mermaid cannot parse descriptive text after syntax.
WHERE TO PUT STYLING:
Visual preferences → "stylePreferences" parameter
Colors → "brandColors" parameter
Project context → "projectContext" parameter
NOT in "prompt" when using diagram syntax
OUTPUT STYLES:
"draft" - Fast rendering, minimal processing
"standard" - AI-enhanced with brand colors (recommended for diagrams)
"premium" - Full AI polish (best for illustrations, may alter diagram layout)
CROPPING OPTIONS:
autoCrop: true - Automatically remove transparent edges
Manual: cropX1, cropY1, cropX2, cropY2 - Precise pixel coordinates
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | The type of image to create | illustration |
| model | No | Model: 'gpt-image-1.5', 'gemini-flash', 'gemini-pro' | |
| cropX1 | No | Manual crop: top-left X | |
| cropX2 | No | Manual crop: bottom-right X | |
| cropY1 | No | Manual crop: top-left Y | |
| cropY2 | No | Manual crop: bottom-right Y | |
| labels | No | Labels for templates/diagrams | |
| prompt | No | For diagrams: Either natural language description OR pure Mermaid/D2/Vega syntax. For illustrations: Describe the image content, style, and composition. Optional when using diagramCode + diagramFormat. | |
| quality | No | Quality setting | |
| autoCrop | No | Auto-crop transparent edges | |
| template | No | Template name for template-based graphics | |
| aspectRatio | No | Preset aspect ratio (e.g., 'og-image' for 1200x630) | |
| brandColors | No | Brand colors as hex codes (e.g., ['#0033A0', '#FF8C00']) | |
| diagramCode | No | Pre-validated diagram syntax (Mermaid/D2/Vega-Lite JSON). When provided, bypasses AI generation/styling and renders directly. Caller is responsible for valid syntax. Must be used with diagramFormat. | |
| outputStyle | No | Polish level: 'draft' (fast), 'standard' (AI-enhanced), 'premium' (full AI polish) | |
| stylePreset | No | Preset style with brand colors | |
| transparent | No | Request transparent background | |
| cornerRadius | No | Corner radius for rounded corners | |
| diagramFormat | No | Format of the diagramCode. Required when diagramCode is provided. Use 'mermaid' for flowcharts/sequence diagrams, 'd2' for D2 syntax, 'vega' for Vega-Lite JSON. | |
| diagramSyntax | No | Preferred diagram syntax | |
| projectContext | No | Description of the project this image is for | |
| autoCropPadding | No | Padding for auto-crop (default: 20) | |
| diagramTemplate | No | Pre-built diagram template | |
| referenceAssetId | No | Asset UUID to use as style reference | |
| stylePreferences | No | Style preferences: 'modern', 'minimalist', 'corporate', etc. | |
| layoutPreservation | No | How strictly to preserve layout during premium polish |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description extensively discloses behavioral traits: it details diagram generation via diagramCode vs natural language, newline encoding, D2 styling constraints, output styles (draft/standard/premium), cropping options, and where to place styling parameters. Annotations only provide basic hints, so the description carries the full burden and delivers thoroughly.
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?
The description is long but well-structured with clear sections, examples, and warnings. It is front-loaded with purpose and usage guidelines. While not concise, every section adds necessary detail given the tool's complexity (26 parameters, diagram support). The length is justified, but could be slightly more streamlined.
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?
Given the tool's complexity and lack of output schema, the description is remarkably complete. It covers all image types, diagram formats, styling options, cropping, and common mistakes. It provides numerous copy-paste ready examples and explains how different parameters interact, ensuring an AI agent can invoke the tool correctly across diverse scenarios.
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?
Despite 100% schema description coverage, the tool description adds substantial value beyond the schema. It provides concrete examples for each parameter grouping, explains the interplay between diagramCode and diagramFormat, warns against invalid usage, clarifies outputStyle effects, and gives best practices for styling. This goes far beyond the schema's basic descriptions.
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?
The description clearly states it generates 'professional, brand-consistent images' and lists specific use cases like blog hero images, OG images, and diagrams. It distinguishes from built-in image generation by highlighting advantages such as pre-configured dimensions, brand consistency, and native diagram support.
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?
A dedicated 'WHEN TO USE THIS TOOL' section explicitly lists scenarios where this tool is preferred over built-in generation. It also provides 'WHY USE THIS INSTEAD' with bullet points and includes common pitfalls like mixing syntax with description in prompts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getOgDataBRead-onlyIdempotentInspect
Get OpenGraph data from a given URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the webpage to analyze meta tags from | |
| cache_ok | No | Whether to use cached results. Set to false to bypass cache and get fresh data. Defaults to true. | |
| use_proxy | No | Whether to use a proxy for the request. Defaults to false. | |
| accept_lang | No | Accept-Language header value to send with the request. Use 'auto' to use the default. Defaults to 'en-US,en;q=0.9'. | |
| full_render | No | Whether to fully render the page with JavaScript before extracting data. Useful for SPAs and JS-heavy sites. Defaults to false. | |
| use_premium | No | Whether to use a premium proxy for the request. Defaults to false. | |
| use_superior | No | Whether to use a superior proxy for the request. Defaults to false. | |
| max_cache_age | No | Maximum cache age in milliseconds. Results older than this will be re-fetched. Defaults to 432000000 (5 days). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds no extra behavioral context (e.g., rate limits, authentication, caching details). It is consistent but does not go beyond the annotations.
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?
Single sentence with no redundant words. Perfectly concise and front-loaded.
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?
Given the tool has 8 parameters and no output schema, the description lacks details on return format, pagination, or common use cases. However, the schema descriptions are thorough, and the annotations cover safety, so the description is minimally adequate but not rich.
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?
Input schema has 100% coverage with descriptions for all 8 parameters. The description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate.
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?
Description clearly states it retrieves OpenGraph data from a URL. Slightly vague due to lack of differentiation from sibling tools like getOgExtract or getOgQuery, but the verb 'Get' and direct reference to OpenGraph data provide adequate specificity.
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?
No guidance on when to use this tool versus alternatives (e.g., getOgExtract, getOgScrapeData). Does not mention prerequisites, limitations, or ideal scenarios, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getOgExtractARead-onlyIdempotentInspect
Extract specified HTML elements from a given URL using OpenGraph's scrape endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | Site to request (full URL) | |
| cache_ok | No | Whether to use cached results. Set to false to bypass cache and get fresh data. Defaults to true. | |
| use_proxy | No | Whether to use a proxy for the request. Defaults to false. | |
| accept_lang | No | Accept-Language header value to send with the request. Use 'auto' to use the default. Defaults to 'en-US,en;q=0.9'. | |
| full_render | No | Whether to fully render the page with JavaScript before extracting. Useful for SPAs and JS-heavy sites. Defaults to false. | |
| use_premium | No | Whether to use a premium proxy for the request. Defaults to false. | |
| use_superior | No | Whether to use a superior proxy for the request. Defaults to false. | |
| html_elements | Yes | Array of HTML selectors to extract from the page | |
| max_cache_age | No | Maximum cache age in milliseconds. Results older than this will be re-fetched. Defaults to 432000000 (5 days). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds that it uses OpenGraph's scrape endpoint but does not elaborate on caching, error handling, or rate limits. Given annotations cover safety, a score of 3 is appropriate.
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?
Single sentence, no redundant information, front-loaded with the core purpose. Every word earns its place.
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?
Despite lacking an output schema and having 9 parameters, the description covers the central function. The schema descriptions for parameters are complete, and the tool's purpose is clear. Could mention that it's read-only or hint at key parameters, but not necessary.
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 schema already documents all parameters. The description does not add any parameter-specific meaning beyond what is in the schema. Baseline 3 is appropriate.
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?
The description 'Extract specified HTML elements from a given URL using OpenGraph's scrape endpoint' clearly states the action (extract), resource (HTML elements from URL), and method (OpenGraph's scrape endpoint). It distinguishes from sibling tools like getOgData (which likely returns general OG data) and getOgScreenshot (which captures images).
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?
No guidance is provided on when to use this tool versus alternatives. The sibling list includes similar tools like getOgScrapeData, but the description does not differentiate usage contexts or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getOgQueryCRead-onlyIdempotentInspect
Query a site with a custom question and response structure using the OG Query endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| site | Yes | Site to request (full URL) | |
| query | Yes | Query to ask about the site | |
| cache_ok | No | Whether to use cached results. Set to false to bypass cache and get fresh data. Defaults to true. | |
| modelSize | No | AI model size to use for the query. 'nano' is fastest/cheapest, 'standard' is most capable. Defaults to 'nano'. | |
| use_proxy | No | Whether to use a proxy for the request. Defaults to false. | |
| accept_lang | No | Accept-Language header value to send with the request. Use 'auto' to use the default. Defaults to 'en-US,en;q=0.9'. | |
| full_render | No | Whether to fully render the page with JavaScript before querying. Useful for SPAs and JS-heavy sites. Defaults to false. | |
| use_premium | No | Whether to use a premium proxy for the request. Defaults to false. | |
| use_superior | No | Whether to use a superior proxy for the request. Defaults to false. | |
| max_cache_age | No | Maximum cache age in milliseconds. Results older than this will be re-fetched. Defaults to 432000000 (5 days). | |
| responseStructure | No | Optional JSON for response structure |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds no behavioral context beyond the endpoint name. It does not mention caching, proxy, or rendering behavior, which are present in the parameters but not summarized.
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?
The description is a single sentence, making it concise but lacking structure. It would benefit from additional key information about the tool's purpose or behavior without becoming verbose.
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?
Given the tool has 11 parameters and no output schema, the description does not address return values, output format, or the AI model aspect. Important aspects like caching behavior and proxy usage are only in parameter descriptions, not summarized. The description feels incomplete for a complex tool.
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?
All 11 parameters have thorough descriptions in the input schema (100% coverage). The tool description itself adds no extra meaning or context for the parameters, so it meets the baseline but does not excel.
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?
The description clearly states the tool queries a site with a custom question and response structure, using a specific endpoint. It is specific enough to distinguish it from generic data retrieval tools, though it does not explicitly differentiate it from sibling tools like getOgData.
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?
The description provides no guidance on when to use this tool vs. alternatives. There is no discussion of use cases, prerequisites, or when to avoid using it, leaving the agent to infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getOgScrapeDataBRead-onlyIdempotentInspect
Scrape data from a given URL using OpenGraph's scrape endpoint
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the webpage to scrape data from | |
| cache_ok | No | Whether to use cached results. Set to false to bypass cache and get fresh data. Defaults to true. | |
| use_proxy | No | Whether to use a proxy for the request. Defaults to false. | |
| accept_lang | No | Accept-Language header value to send with the request. Use 'auto' to use the default. Defaults to 'en-US,en;q=0.9'. | |
| full_render | No | Whether to fully render the page with JavaScript before scraping. Useful for SPAs and JS-heavy sites. Defaults to false. | |
| use_premium | No | Whether to use a premium proxy for the request. Defaults to false. | |
| use_superior | No | Whether to use a superior proxy for the request. Defaults to false. | |
| max_cache_age | No | Maximum cache age in milliseconds. Results older than this will be re-fetched. Defaults to 432000000 (5 days). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint=false. The description adds that it uses OpenGraph's scrape endpoint, which is a read operation consistent with annotations. No contradictions, but no further behavioral traits (e.g., rate limits, data freshness) disclosed.
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?
Single sentence, front-loaded with verb and resource, no unnecessary words. Efficient and to the point.
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?
With 8 parameters and no output schema, the description is too terse. It does not explain the purpose of the tool's many configuration options or what the return data looks like, leaving the agent to rely solely on param descriptions.
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 coverage is 100%, so baseline is 3. The description does not add meaning beyond the parameter descriptions already present in the schema. It does not synthesize or clarify the many options.
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?
The description uses a specific verb 'scrape' and identifies the resource 'data from a given URL' via 'OpenGraph's scrape endpoint'. It clearly states what the tool does but does not explicitly differentiate from sibling tools like getOgData or getOgExtract, which may overlap in functionality.
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?
No guidance on when to use this tool versus alternatives, no preconditions or postconditions mentioned. The description fails to set expectations for when to use parameters like cache_ok, use_proxy, or full_render.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getOgScreenshotBRead-onlyIdempotentInspect
Get a screenshot of a given URL using OpenGraph's screenshot endpoint
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the webpage to screenshot | |
| format | No | Image format for the screenshot. Options: 'jpeg', 'png', 'webp'. Defaults to 'jpeg'. | |
| quality | No | Image quality (10-80, rounded to nearest 10). Lower values = smaller file size. Defaults to 80. | |
| cache_ok | No | Whether to use cached results. Set to false to bypass cache and get fresh data. Defaults to true. | |
| selector | No | CSS selector to capture a specific element instead of the full page. | |
| dark_mode | No | Whether to enable dark mode when capturing the screenshot. Defaults to false. | |
| full_page | No | Whether to capture the full scrollable page instead of just the viewport. Defaults to false. | |
| use_proxy | No | Whether to use a proxy for the request. Defaults to false. | |
| dimensions | No | Viewport dimensions for the screenshot. 'lg' (1920x1080), 'md' (1366x768), 'sm' (1024x768), 'xs' (375x812 mobile). Defaults to 'md'. | |
| accept_lang | No | Accept-Language header value to send with the request. Use 'auto' to use the default. Defaults to 'en-US,en;q=0.9'. | |
| full_render | No | Whether to fully render the page with JavaScript before taking the screenshot. Useful for SPAs and JS-heavy sites. Defaults to false. | |
| use_premium | No | Whether to use a premium proxy for the request. Defaults to false. | |
| use_superior | No | Whether to use a superior proxy for the request. Defaults to false. | |
| capture_delay | No | Delay in milliseconds to wait before capturing the screenshot (0-10000). Useful for pages with animations. | |
| max_cache_age | No | Maximum cache age in milliseconds. Results older than this will be re-fetched. Defaults to 432000000 (5 days). | |
| exclude_selectors | No | Comma-separated CSS selectors of elements to hide before capturing the screenshot. | |
| block_cookie_banner | No | Whether to attempt to block cookie consent banners. Defaults to true. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, which cover safety and idempotency. The description adds minimal additional behavioral context (e.g., 'using OpenGraph's screenshot endpoint'), but does not explain caching, error handling, or output format. With good annotation coverage, a score of 3 is appropriate.
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?
The description is a single concise sentence that front-loads the action. It contains no fluff and earns its place by clearly stating the tool's purpose.
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?
Despite having a rich schema and 17 parameters, the description does not explain the return format (e.g., binary image data), any limitations, or how to handle the output. An agent lacks enough high-level context to fully understand what to expect from the tool invocation.
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 schema already explains all 17 parameters in detail. The description itself adds no additional meaning beyond the schema. Baseline 3 is correct.
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?
The description clearly states the action ('Get a screenshot') and the resource ('a given URL using OpenGraph's screenshot endpoint'), and it distinguishes from sibling tools like getOgData and getOgExtract which focus on data extraction.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or tips for choosing among the sibling screenshot-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
inspectImageSessionARead-onlyIdempotentInspect
Retrieve detailed information about an image generation session and all its assets.
Returns:
Session metadata (creation time, name, status)
List of all assets with their prompts, toolchains, and status
Parent-child relationships showing iteration history
Use this to:
Review what was generated in a session
Find asset IDs for iteration
Understand the generation history and toolchains used
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | The session UUID to inspect |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is clear. The description adds value by detailing the return structure (metadata, assets, relationships), but does not contradict annotations.
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?
The description is concise and well-structured: a one-sentence summary, then bullet lists for returns and use cases. Every sentence is informative and free of redundancy.
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?
Given the absence of an output schema, the description adequately explains what is returned (metadata, assets, relationships) and the use cases. It could specify data types or pagination, but overall it is complete for a read-only tool with one parameter.
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 coverage is 100% and the parameter 'sessionId' has a clear description in the schema ('The session UUID to inspect'). The description does not add further semantic meaning beyond the schema.
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?
The description clearly states the tool retrieves detailed information about an image generation session and its assets, specifying the resource (session) and verb (inspect). It distinguishes itself from sibling tools, which focus on export, generation, or other operations.
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?
The description provides explicit use cases (review, find asset IDs, understand history) in bullet points. While it does not mention when not to use it, the context of sibling tools makes the scope clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
iterateImageAInspect
Refine, modify, or create variations of an existing generated image.
Use this to:
Edit specific parts of an image ("change the background to blue", "add a title")
Apply style changes ("make it more minimalist", "use darker colors")
Fix issues ("remove the text", "make the icon larger")
Crop the image to specific coordinates
For diagram iterations:
Include the original Mermaid/D2/Vega source in your prompt to preserve structure
Be explicit about visual issues (e.g., "the left edge is clipped")
| Name | Required | Description | Default |
|---|---|---|---|
| cropX1 | No | Crop: X coordinate of the top-left corner in pixels | |
| cropX2 | No | Crop: X coordinate of the bottom-right corner in pixels | |
| cropY1 | No | Crop: Y coordinate of the top-left corner in pixels | |
| cropY2 | No | Crop: Y coordinate of the bottom-right corner in pixels | |
| prompt | Yes | Detailed instruction for the iteration. Be specific about what to change. Examples: 'Change the primary color to #0033A0', 'Add a subtle drop shadow' | |
| assetId | Yes | The asset UUID of the image to iterate on | |
| sessionId | Yes | The session UUID containing the image to iterate on |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and non-destructive. Description adds specifics: it modifies images, requires an existing asset, and includes diagram iteration tips. No contradictions.
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?
Well-structured with clear first sentence, bulleted use cases, and a distinct note for diagrams. No redundant text; every sentence adds value.
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?
Covers purpose, usage scenarios, parameter hints, and special instructions for diagrams. Adequate for a tool with 7 parameters and no output schema.
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 coverage is 100%, so schema already documents all parameters. Description adds example prompts and diagram-specific guidance, adding marginal value beyond schema.
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?
The description clearly states it refines/modifies/creates variations of existing images, uses specific verbs, and distinguishes from siblings like generateImage (creates new) and exportImageAsset (exports). Use cases listed make purpose unmistakable.
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?
Lists explicit use cases ('Use this to:') with examples. Lacks explicit when-not-to-use, but context from sibling tools makes alternatives clear. Could be more definitive about exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!