Opengraph io MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.3.6
Disambiguation4/5
Most tools have clearly distinct purposes (e.g., discover vs. audit vs. report, generate vs. iterate vs. export). However, getOgData, getLinkPreview, and previewPageAudit all deal with social previews, which could cause minor confusion. Overall, boundaries are well-defined.
Naming Consistency5/5
All tools follow a consistent verb_noun camelCase pattern (e.g., generateImage, getOgData, startSiteAudit). The naming is predictable and descriptive, with no mixing of conventions.
Tool Count5/5
With 16 tools, the server covers both image generation and site auditing without being overwhelming. Each tool serves a distinct and necessary function within its domain.
Completeness5/5
The tool set covers the full lifecycle: site discovery, audit initiation, status polling, report retrieval, single-page preview, and multiple data extraction methods. Image generation includes creation, iteration, export, and session inspection. No obvious gaps.
Average 4.5/5 across 16 of 16 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 34 commits in the last 12 weeks
- Last stable release on July 1, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under ISC License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare `readOnlyHint: true` and `destructiveHint: false`. The description adds credit consumption details (100 or 200 credits) and a version note. No contradictions; additional behavioral context beyond annotations is minimal but adequate.
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 concise: two sentences plus a brief note. It front-loads the core purpose and critical details (API credit usage, version status). Every sentence adds value with no 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?
Given high schema coverage, existence of an output schema (not shown), and annotations that cover safety, the description is mostly complete. It could mention return format or pagination, but output schema likely handles that. Overall adequate for the tool's complexity.
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% (all 18 parameters have descriptions). The description adds no extra parameter meaning beyond what the schema provides, except for highlighting `responseStructure` for structured data. Baseline score 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 function: 'Ask a natural-language question about the content of any URL and receive an AI-generated answer.' It distinguishes from sibling tools like `getOgData` or `getOgExtract` by focusing on natural-language queries and optional structured extraction via `responseStructure`.
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?
The description implies usage for querying URL content with NL questions but provides no explicit guidance on when to use this tool versus alternatives (e.g., `getOgExtract` for structured data without AI). No when-not or exclusion cases are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint: true, but the description does not clarify what destructive action occurs (e.g., does exporting consume or delete the asset?). The description primarily describes a read-like operation (returning base64 and metadata), which may conflict with the destructive hint, though not explicitly contradictory.
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?
The description is well-structured with a clear header, explanatory text, and usage examples. It is slightly repetitive in the usage section (mirroring function call), but overall efficient and front-loaded with key information.
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 the tool has an output schema (no need to describe return values), the description covers dependencies, transport-specific behavior, and usage flow. It is fully adequate for correct invocation.
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%, and the description adds meaningful context for each parameter: sessionId and assetId are UUIDs from a generation step, and destinationPath is conditionally available only on local/stdio transport. This enhances understanding beyond the schema.
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 exports a generated image asset by session and asset ID. It uses specific verbs and resource names, and the context distinguishes it from siblings like generateImage or inspectImageSession.
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 provides explicit usage context: use after generateImage with sessionId and assetId, and mentions optional local disk saving. It lacks explicit when-not-to-use or alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, etc. Description adds value by disclosing the 6000-character cap, the need for full_render on SPAs, and default behavior of stripping navigation/ads. No contradictions with annotations.
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?
Description is well-structured with a clear hierarchy: purpose, important note, character cap, then sibling comparison. Front-loaded with essential info. Slightly verbose due to sibling list, but acceptable given complexity.
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 tool with 23 parameters and an output schema, the description covers main use cases, default behavior, and critical caveats. It mentions the markdown field and cap. Could be more explicit about output structure, but output schema compensates.
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 baseline is 3. Description reinforces key parameters (include_tags, exclude_tags, full_render) but does not add significant meaning beyond what the schema already provides. Adequate but not superior.
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?
Description clearly states 'Convert any URL's HTML into clean Markdown' and distinguishes from siblings by listing alternative tools (getOgData, getOgScrapeData, etc.) with specific use cases. The verb+resource is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool vs alternatives via the 'Pick the right tool' section. Also includes caveats for JavaScript-heavy pages, advising when to set full_render. No missing exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. Description adds synchronous nature, immediate results, that it does not count against monthly audit quota, and requires OAuth authentication. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, no wasted words, front-loaded with core purpose, then usage triggers, then behavioral notes, then alternative. Perfectly structured.
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?
Given a single parameter, good annotations, and an output schema, the description covers purpose, usage, behavioral constraints, and the return format in a summary. Completeness is high.
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 coverage is 100% with a single 'url' parameter that already has a description. The description does not add additional parameter semantics beyond what the schema 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 clearly states the verb 'Check' and resource 'URL', specifies the platforms (Facebook, Twitter/X, LinkedIn, Google), and distinguishes itself from sibling tool 'startSiteAudit' for full multi-page audits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists example user queries that trigger the tool ('check the link preview', 'how does this page look when shared', 'check my og tags', etc.) and provides an explicit alternative ('For a full multi-page audit... use startSiteAudit instead').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds valuable behavioral context: three data sources merging behavior, automatic gap-filling by hybridGraph, and hints about defaults (retry, cache_ok). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, followed by a clear sibling comparison table. Every sentence adds value, and it is concise given the complexity (24 parameters).
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?
Given the complexity (24 parameters, output schema exists), the description explains the data sources, hybrid nature, and usage guidance. It could mention that the output schema provides detailed field descriptions, but overall it is complete enough.
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 baseline is 3. The description does not elaborate on individual parameters beyond the schema, but provides overall context about data sources and output structure that helps understand parameter relevance.
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 fetches Open Graph metadata, HTML-inferred tags, and hybrid social preview data. It specifies the verb 'Fetch' and resource, and distinguishes from siblings by listing what each sibling tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a 'Pick the right tool' section that tells when to use getOgData versus alternatives like getOgMarkdown, getOgScrapeData, etc. It also advises using hybridGraph as the primary source.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds the crucial constraint that audit must be COMPLETE, which is not in annotations. It also lists report contents, providing additional context beyond safety profile.
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?
The description is well-structured with bullet points and a decision table. It is front-loaded with the main purpose. Slightly verbose but every section adds value; could be trimmed slightly but still effective.
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 the presence of output schema, annotations, and sibling tools, the description is fully complete. It enumerates report contents, specifies prerequisites, and provides clear usage guidance, leaving no ambiguity for an AI agent.
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 coverage is 100%, so baseline is 3. The description mentions the auditId parameter and its required status, but this is already documented in the schema. No additional parameter details beyond schema are provided.
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 specific verb 'Retrieve' and resource 'full structured report for a completed site audit'. It distinguishes from siblings like getSiteAuditStatus and previewPageAudit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the prerequisite (audit must be COMPLETE) and names the alternative tool getSiteAuditStatus for checking progress. The 'Pick the right tool' section clearly differentiates when to use each sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint, idempotentHint, destructiveHint. The description adds context about the return format (hosted screenshotUrl), usage in browser/img tag, and proxy/retry behaviors, which are beyond what annotations provide.
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?
The description is well-organized: opening sentence, return format explanation, sibling comparison. It is efficient but the sibling list is somewhat lengthy; still no wasted content.
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?
Given the tool's complexity (24 parameters, many options), the description covers key capabilities, return value, and usage notes. It lacks only detailed output schema but mentions the hosted URL, so completeness is high.
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 baseline is 3. The description adds meaningful summary of key parameter groups (full-page, viewport, dark mode, etc.) and their effects, providing extra context beyond individual schema descriptions.
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 captures a screenshot via OpenGraph.io API v3, lists key features, and distinguishes from siblings by presenting a 'Pick the right tool' list with each sibling's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides a 'Pick the right tool' section that details when to use this screenshot tool versus alternatives like getOgData, getOgMarkdown, etc., offering clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds behavioral context: it returns progress counters and summary scores after audit finishes, which is beyond what annotations convey. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: first sentence defines purpose, second explains polling pattern, third differentiates tools. No wasted words, all sentences earn their place.
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 the tool is simple (single parameter, output schema exists), the description covers all necessary context: polling usage, statuses, timing, and relation to sibling tools. No gaps.
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?
Only one parameter (auditId) with schema description 'The audit ID returned by startSiteAudit.' Schema coverage is 100%, so the description adds no extra meaning beyond what the schema already provides. Baseline 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 polls the status of a running site audit and explicitly lists possible statuses (QUEUED, CRAWLING, etc.). It distinguishes from siblings like getSiteAuditReport by specifying this is for progress polling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: call every 5-10 seconds after startSiteAudit until COMPLETE, then switch to getSiteAuditReport. Also includes a 'Pick the right tool' section comparing with getSiteAuditReport.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false. The description adds valuable context beyond that by detailing what information is returned (metadata, assets, relationships), which helps the agent understand the tool's output without contradicting annotations.
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 concise, uses bullet points for clarity, and front-loads the main purpose. Every sentence adds value without redundancy.
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 the output schema exists, the description covers the essential aspects: returns session metadata, asset lists, and relationships. It is complete for a read-only inspection tool with clear use cases.
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 coverage is 100%, with the only parameter sessionId having a format and description. The description does not add additional semantic details about the parameter, so baseline 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 'Retrieve detailed information about an image generation session and all its assets,' specifying the verb, resource, and scope. It distinguishes from sibling tools like generateImage and iterateImage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists three use cases: reviewing session content, finding asset IDs for iteration, and understanding history/toolchains. This provides clear guidance on when to use this tool, with no mention of when not to use, but the use cases imply exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (mutation) and destructiveHint=false. The description adds value by detailing behaviors like editing parts, style changes, cropping, and fixing issues, and advising to include source for diagrams to preserve structure.
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 well-structured with bullet points and numbered steps, front-loading the main purpose. Every sentence adds value, and it is appropriately concise without being terse.
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 the tool's complexity (7 parameters, 3 required, output schema present), the description covers editing, cropping, and diagram iterations with guidance on preserving source. It fulfills all informational needs for correct invocation.
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%, providing descriptions for all 7 parameters. The description enhances this with examples for the prompt parameter (e.g., 'Change the primary color to #0033A0') and clarifies the cropping coordinates as top-left and bottom-right, aiding the agent.
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 specific verbs like 'refine', 'modify', and 'create variations' on an existing image, clearly distinguishing it from sibling tools like generateImage (new image) and exportImageAsset (exporting). The list of use cases further clarifies the scope.
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 explicitly states 'Use this to:' followed by concrete scenarios, and provides a specific 'For diagram iterations:' section with numbered steps. While it doesn't explicitly state when NOT to use, the purpose is clear and contrasts well with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral context: crawling and sitemap parsing, return of URL list grouped by depth, remaining audit quota, and 'siteContextText' to be passed to startSiteAudit. No contradiction with annotations.
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 well-structured and front-loaded: purpose first, then return info, usage instructions, and sibling differentiation. Every sentence adds value without unnecessary fluff.
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?
The description fully explains the tool's input (one domain parameter), output (URLs grouped by depth, audit quota, siteContextText), and how to use the output (pass siteContextText to startSiteAudit, discuss with user). With an output schema present, the description covers all necessary 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 coverage is 100% with one parameter 'domain' already described as needing protocol. The description does not add new semantic meaning beyond the schema; it repeats the requirement to include the protocol. Baseline 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 purpose: 'Discover all pages on a domain by crawling it and parsing its sitemap.' It uses a specific verb 'discover' and resource 'all pages on a domain'. The sibling differentiation section explicitly distinguishes it from startSiteAudit and previewPageAudit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use: 'Use this as the first step before starting a full site audit.' It also provides a post-call instruction: present URL list to user and ask for page selection. The 'Pick the right tool' section gives clear alternatives and steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description extensively discloses behaviors: three methods for diagram creation, newline encoding, D2 syntax rules, output styles (draft/standard/premium), cropping options, and warnings about mixing syntax. Annotations indicate readOnlyHint=false and destructiveHint=false, and the description aligns with these, providing additional context about iterative refinement and non-destructive edits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively long, containing multiple sections, numerous examples, and detailed warnings. While well-organized with headings, it lacks conciseness; an AI agent would need to parse a large amount of text to extract key information. Front-loading is present but the sheer volume makes it inefficient.
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 the tool's complexity (26 parameters, 0 required, output schema exists), the description is highly complete. It covers all major usage patterns, error-prone cases (e.g., mixing syntax), parameter interdependencies, and provides practical examples. The output schema exists, so return value explanation is not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema description coverage, the description adds substantial value beyond the schema: it explains how diagramCode and prompt interact, provides copy-paste ready examples for each diagram format, details aspect ratio presets, stylePreset meanings, outputStyle effects, and cropping usage. This greatly enhances understanding of parameter usage.
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 purpose: 'Generate professional, brand-consistent images optimized for web and social media.' It lists specific use cases (blog heroes, OG images, social cards, diagrams, etc.) and provides quick start examples, distinguishing it from sibling tools which are URL/image inspection tools, not generation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a section 'WHEN TO USE THIS TOOL (prefer over built-in image generation)' listing explicit scenarios and 'WHY USE THIS INSTEAD OF BUILT-IN IMAGE GENERATION' with reasons. It provides clear context for when to use this tool versus alternatives, and since siblings are not image generation tools, the guidelines are unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds mode behavior, default values (e.g., html_elements default list), response shapes per mode, and proxy escalation logic. No contradictions with annotations.
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?
The description is relatively long but well-structured with clear sections (modes, response shapes, special params, sibling comparison). Every sentence has purpose, though a few technical details could be tightened.
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?
Given 25 parameters and an output schema, the description covers the two primary modes, default behaviors, and important options. It lacks some edge-case clarifications but is sufficiently complete for an agent to use the tool correctly.
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 baseline is 3. The description adds significant meaning: explains the two parameter groups (html_elements vs selectors) with examples, describes defaults, and clarifies how modes affect output. Some parameters (e.g., retry, cache_ok) get less attention, but overall adds value.
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 it extracts specific content from URLs via OpenGraph.io API v3, and lists two distinct modes with examples. It distinguishes itself from siblings by contrasting each sibling's purpose in a dedicated bullet list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use tag-based vs selector-based mode, and provides a complete sibling comparison table. It also gives guidance on when to use parameters like full_render and wait_for_selector.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds that the check is synchronous, returns immediately, does not persist an audit, and does not count against quota, complementing annotations perfectly.
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 concise, well-structured: first sentence states core action and output, then clarifies synchronous/non-persisting nature, then lists score labels, then provides tool comparison. No superfluous sentences.
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 the tool has an output schema, the description sufficiently explains the return values (score, label, breakdown, issues, mock previews) and score ranges. It covers all necessary context for an agent to use this tool effectively without needing to inspect the output schema.
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 coverage is 100% for the single 'url' parameter, with description 'The full URL of the page to audit (e.g. https://example.com/product).' The tool description repeats the example but adds no new semantic value beyond the schema, so baseline 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 explicitly states it runs an instant quality audit of a single URL and lists the returned data (score, label, breakdown, issues, mock previews). It clearly differentiates from sibling tools like startSiteAudit which is async and crawls an entire domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description directly provides a 'Pick the right tool' section comparing previewPageAudit (instant, no quota) with startSiteAudit (async, uses quota), giving explicit guidance on when to use each.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that first 3000 chars are in text response, full HTML in structured field, explains auto_render vs full_render, and retry behavior. Annotations already declare readOnlyHint, etc., and description adds valuable context without contradiction.
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?
Well-structured with clear paragraphs, but slightly verbose. Could be trimmed slightly, but overall effective.
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 the high parameter count, rich schema descriptions, and output schema, the description provides sufficient context for correct tool invocation.
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 baseline is 3. Description adds extra context for auto_render and full_render parameters, earning a 4.
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 scrapes raw HTML and distinguishes from siblings by listing their specific use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides a 'Pick the right tool' section with each sibling's purpose, giving clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that audits are asynchronous and can take several minutes, returns an audit ID, and instructs to use getSiteAuditStatus for polling. Also explains behavior when `urls` is omitted (backend crawls). No contradiction with annotations (readOnlyHint=false, etc.).
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?
The description is well-structured and front-loaded with core purpose, then parameter guidance, then async behavior and tool selection. It is somewhat lengthy but every sentence adds value. Minor redundancy in repeating 'audit all' explanation could be trimmed.
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 complexity (asynchronous, multiple URL sources, polling), and full schema coverage plus output schema existence, the description is complete. It covers all aspects needed for correct tool invocation and result handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant context: for `urls`, explains sourcing methods; for `domain`, includes protocol requirement; for `pagesRequested`, explains default and plan limits; for `siteContextText`, explains its role in enriching the overview. This goes well beyond schema descriptions.
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 action ('start a full site audit') and what it audits (Open Graph, social media, SEO metadata). It distinguishes from sibling tools by listing alternatives and their purposes, such as discoverSiteUrls for crawl-based discovery and getSiteAuditStatus for polling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool vs. siblings, including a dedicated section 'Pick the right tool'. Explains how the `urls` array can be sourced from discoverSiteUrls, codebase scan, sitemap, or manual list, and that calling discoverSiteUrls first is not required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![opengraph-io-mcp MCP server](https://glama.ai/mcp/servers/securecoders/opengraph-io-mcp/badges/card.svg)](https://glama.ai/mcp/servers/securecoders/opengraph-io-mcp)

Score Badge

Copy to your README.md:

[![opengraph-io-mcp MCP server](https://glama.ai/mcp/servers/securecoders/opengraph-io-mcp/badges/score.svg)](https://glama.ai/mcp/servers/securecoders/opengraph-io-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/securecoders/opengraph-io-mcp'

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