Opengraph IO MCP

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

While annotations declare idempotentHint=true and destructiveHint=true, the description adds crucial context about the dual output behavior (inline base64 return vs disk save) and the transport restriction for file writing. It does not contradict annotations; 'saving to disk' aligns with destructiveHint=true.

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?

Perfectly structured with clear separation between purpose, return value description, and usage examples. No filler text; every sentence provides actionable information. The front-loaded purpose statement immediately orients the agent.

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, the description explicitly documents the return format ('base64 along with metadata') and the conditional file-system side effects. Given the 3-parameter complexity and destructive annotations, this provides sufficient context for safe 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 coverage is 100%, establishing a baseline of 3. The description adds value through the USAGE section showing realistic parameter values and clarifying the dependency between generateImage outputs (sessionId/assetId) and this tool's inputs, effectively documenting the workflow semantics.

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 opens with a specific verb ('Export') and resource ('generated image asset') and clarifies the lookup method ('by session and asset ID'). It clearly distinguishes from sibling 'generateImage' (which creates assets) by stating this tool exports existing assets.

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?

Contains an explicit USAGE section that establishes the workflow sequence ('After generating an image with generateImage...'), provides concrete invocation examples, and specifies the transport constraint for the optional destinationPath parameter ('local/stdio only').

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

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

Annotations declare non-idempotent write operations (readOnlyHint:false, idempotentHint:false). Description adds crucial behavioral context: output style differences (draft/standard/premium), diagram rendering pipeline (bypasses AI when using diagramCode), and cropping behavior. Does not mention return format or rate limits.

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 headers and front-loaded purpose. Length is substantial but justified by complexity (26 parameters, multiple distinct modes). Copy-paste examples earn their place by preventing syntax errors, though some repetition in diagram examples could be condensed.

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?

Comprehensive on inputs and use cases, but lacks description of return values/output format despite no output schema existing. Also fails to explicitly reference sibling tool 'iterateImage' for the 'iterative refinement' capability mentioned, only describing it as a feature.

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 has 100% coverage (baseline 3). Description adds significant value through extensive parameter interaction examples (e.g., 'Can omit prompt entirely when using diagramCode', 'Must be used with diagramFormat'), valid combination patterns, and syntax-specific guidance for Mermaid/D2/Vega that schema cannot convey.

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?

Opens with specific verb+resource ('Generate professional, brand-consistent images') and explicitly distinguishes from siblings via 'WHY USE THIS INSTEAD OF BUILT-IN IMAGE GENERATION' and comparison to generic generation capabilities.

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?

Contains explicit 'WHEN TO USE THIS TOOL' section listing specific scenarios (OG images, diagrams, QR codes), 'WHY USE THIS INSTEAD' comparing to alternatives, and 'WRONG - DO NOT' anti-patterns that prevent misuse.

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

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

Annotations cover safety profile (readOnly, idempotent, non-destructive), so the description doesn't need to carry that burden. However, the description adds no context about what OpenGraph data includes (title, image, description), error handling for invalid URLs, or the impact of caching/proxy options beyond what parameter descriptions provide.

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?

Extremely brief at seven words with no redundancy. While efficiently structured, it arguably errs on the side of under-specification given the tool's complexity (8 parameters including proxy tiers and rendering modes).

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 8 parameters supporting complex configurations (premium proxies, JavaScript rendering, cache control) and no output schema, the description is insufficient. It should explain what data structure is returned or when to use premium/superior proxies versus standard requests.

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?

With 100% schema description coverage, the input parameters are fully documented in the structured schema. The description doesn't add parameter semantics, but given the comprehensive schema, it doesn't need to. Baseline score applies.

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 OpenGraph data using a specific URL, providing a concrete verb and resource. However, it fails to differentiate from siblings like 'getOgExtract', 'getOgQuery', or 'getOgScrapeData', leaving ambiguity about which OpenGraph tool to select.

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 like getOgExtract or getOgScreenshot. The description lacks prerequisites, exclusion criteria, or scenario-based recommendations for the various proxy and rendering options.

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

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

Annotations already declare readOnly/idempotent/destructive status, so the safety profile is covered. The description adds context about using 'OpenGraph's scrape endpoint' but omits behavioral details like return format (structured vs HTML strings), error handling for missing elements, or rate limiting.

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 efficiently conveys the core operation without redundancy. Every word earns its place: verb (Extract), target (HTML elements), source (URL), and mechanism (OpenGraph endpoint).

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 9-parameter tool with complex options (rendering, multiple proxy tiers, caching), the description is minimal but adequate given the annotations present. However, it lacks explanation of output structure and trade-offs between proxy options, which would help agents configure requests appropriately.

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?

With 100% schema description coverage, the structured fields carry the parameter documentation. The description references 'specified HTML elements' and 'given URL' which map to the schema parameters, but adds no additional semantic context like selector syntax examples or URL format requirements 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 extracts HTML elements from URLs using OpenGraph's scrape endpoint. It distinguishes from siblings like getOgData/getOgScrapeData by specifying 'HTML elements' rather than generic metadata or data scraping, though it could explicitly contrast with these alternatives.

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 provided on when to use this versus sibling tools (getOgScrapeData, getOgScreenshot) or when to enable specific options like full_render (for SPAs) or the various proxy tiers (use_proxy vs use_premium vs use_superior).

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

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

While annotations already indicate read-only, idempotent, and open-world characteristics, the description adds minimal behavioral context beyond mentioning 'custom question' capabilities. It doesn't explain error handling (what if the site blocks the proxy?), the AI processing nature implied by modelSize, or the differences between the three proxy tiers (use_proxy, use_premium, use_superior).

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, front-loaded sentence with no filler words. It efficiently conveys the core concept. However, given the tool's complexity (11 parameters including AI configuration), extreme brevity becomes a liability for completeness rather than a virtue of conciseness.

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 11 parameters involving AI model selection, multiple proxy layers, caching strategies, and JavaScript rendering options, the description is underspecified. With no output schema provided, the description should explain the return format or response characteristics, which it fails to do.

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?

With 100% schema description coverage, the baseline is 3. The description mentions 'custom question' and 'response structure', which align with the 'query' and 'responseStructure' parameters, but adds no additional semantic context, examples, or format guidance beyond what the schema already provides.

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 states a clear action ('Query a site') and specifies the key differentiating features ('custom question and response structure') that distinguish it from siblings like getOgData. However, it doesn't explicitly clarify when to prefer this over getOgExtract or getOgScrapeData for different data retrieval needs.

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?

There is no guidance on when to use this tool versus the sibling OG tools (getOgData, getOgExtract, getOgScrapeData). It fails to mention prerequisites like valid URLs, cost implications of different model sizes, or when to bypass cache.

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

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

The description identifies the service ('OpenGraph's scrape endpoint') but adds little beyond the annotations. It does not disclose what data format is returned (structured metadata? HTML?), error handling behavior for invalid URLs, or the implications of the various proxy/cache settings. Annotations cover the safety profile (read-only, idempotent), so the description's burden is lighter.

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 10-word sentence with no redundancy. While appropriately front-loaded, it is arguably too concise for a tool with complex behavioral dimensions (caching, JavaScript rendering, proxy tiers), leaving significant gaps in contextual completeness.

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 8 parameters including complex options like full_render, use_premium, and max_cache_age, and no output schema, the description is insufficient. It fails to specify what data is returned (OpenGraph tags, page content, JSON structure) or explain the behavioral differences between the three proxy modes.

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?

With 100% schema description coverage across 8 parameters, the schema carries the full semantic load. The description mentions no parameters, but per the rubric, high schema coverage establishes a baseline of 3. No additional parameter context (examples, interdependencies between proxy settings) is provided in the description.

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 states the basic action ('Scrape data') and target ('URL') and mentions the specific 'OpenGraph's scrape endpoint'. However, with siblings like getOgData, getOgExtract, and getOgQuery, it fails to clarify what distinguishes 'scrape' from these alternatives or when to prefer this endpoint.

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 the numerous sibling OpenGraph tools (getOgData, getOgExtract, getOgQuery, getOgScreenshot). There is no mention of prerequisites, rate limits, or when to use the premium/superior proxy options versus standard scraping.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by identifying the external dependency ('OpenGraph's screenshot endpoint'), which contextualizes the openWorldHint=true. However, it fails to disclose rate limits, authentication requirements, or what happens when a URL is unreachable.

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 of appropriate length with action-frontloaded structure ('Get a screenshot...'). No redundant or filler text; every word contributes to understanding the tool's core function.

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?

While the input schema is thoroughly documented (100% coverage), the description lacks any indication of what the tool returns (image binary, URL, or base64 string) given the absence of an output schema. For a 17-parameter external API tool, specifying the return format would significantly improve agent usability.

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?

With 100% schema description coverage, the input schema comprehensively documents all 17 parameters including defaults, ranges, and formats. The description mentions 'given URL' which loosely references the required parameter, but adds no semantic detail beyond the schema. Baseline 3 is appropriate for high-coverage schemas.

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'), resource ('URL'), and method ('using OpenGraph's screenshot endpoint'). It distinguishes from siblings like generateImage (creation vs. capture) and other getOg* tools (data/query/extract vs. visual screenshot) by specifying 'screenshot endpoint', though it could explicitly contrast with getOgScrapeData.

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 provided on when to use this tool versus alternatives like generateImage (for AI-generated images) or getOgExtract (for text content). No mention of prerequisites, costs, or rate limiting considerations despite being an external API call.

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

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

While annotations declare readOnly/idempotent hints, description adds substantial behavioral context: specific return structure (session metadata, asset prompts/toolchains, parent-child relationships) and reveals the iteration history tracking capability. 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.

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

Excellent structure with front-loaded action statement, followed by 'Returns:' and 'Use this to:' sections. Zero wasted words; every bullet provides distinct value regarding output structure or use cases.

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?

Compensates effectively for missing output schema by detailing return structure (metadata, assets with prompts/status, parent-child relationships). For a single-parameter read tool, description provides sufficient context for correct invocation and result interpretation.

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% with sessionId fully documented as 'The session UUID to inspect'. Description does not add parameter-specific semantics beyond the schema, which is acceptable given complete schema coverage establishes the baseline.

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?

Opens with specific verb 'Retrieve' + clear resource 'image generation session and all its assets'. Distinct from sibling tools like generateImage (create) and iterateImage (modify), establishing clear scope as an inspection/read operation.

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?

'Use this to:' section explicitly lists three concrete scenarios including 'Find asset IDs for iteration', which implicitly guides users toward the iterateImage sibling tool. Lacks explicit 'when not to use' exclusions, but provides strong positive guidance.

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

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

Annotations declare openWorldHint=true and readOnlyHint=false. Description adds valuable behavioral context not in annotations: diagram workflow requirements (preserving Mermaid/D2/Vega structure), coordinate-based cropping capability, and the iterative nature of changes. 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.

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

Perfectly structured with front-loaded purpose statement, bulleted use cases for scannability, and dedicated section for diagram-specific instructions. No wasted words; every sentence provides actionable guidance. Length is appropriate for complexity (7 parameters with specific workflows).

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?

Comprehensive coverage of input requirements and usage patterns. With 100% schema coverage and good annotations, description adequately covers tool behavior. Minor deduction: no output schema exists, and description omits what the tool returns (e.g., new asset ID vs. in-place modification), though annotations hint at non-destructive behavior.

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%, establishing baseline 3. Description mentions cropping functionality (mapping to cropX/Y parameters) and provides domain-specific prompt guidance for diagrams, adding slight value beyond schema. However, does not significantly expand on parameter semantics already well-documented in schema properties.

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?

Opens with specific verbs (Refine, modify, create variations) and clear resource (existing generated image). Implicitly distinguishes from sibling 'generateImage' by emphasizing 'existing' and lists specific capabilities (edit parts, style changes, crop) that define its scope.

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?

Provides explicit 'Use this to:' bullet list covering four distinct use cases (editing, styling, fixing, cropping). Includes domain-specific guidance for diagram iterations with numbered steps. Lacks explicit 'when not to use' or named sibling alternatives (e.g., 'use generateImage for new images'), preventing a 5.

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