OG Stamp

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

With no annotations, the description does the work: it discloses that the tool fetches the page, extracts title/description/favicon/theme-color, and returns a stable image URL suitable for og:image. It does not cover failure behavior or caching, but for a generation tool these are secondary; the main behavioral facts are present.

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 definition is tightly structured: purpose, mechanism, output, and customization rule each occupy one short sentence, with no filler or repeated schema content. The key usage scope ('existing public page with no fields to fill in') is 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?

The output contract is stated (stable image URL) and the automatic behavior is explained, so a simple URL-based call is well supported. But the optional parameters are left vague, the meaning of 'any field can be overridden' is not mapped to the schema, and the relationship with render_og_image is unaddressed, leaving gaps for a tool with 5 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 only 20% (only url has a description), and the description does not explain font, size, theme, or layout beyond the generic 'Any field can be overridden.' The enum names are self-evident, but the description fails to compensate for the missing parameter-level guidance, so the agent must infer meanings from the values.

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 names a concrete action ('Build an Open Graph card') and a clear resource ('an existing public page'), and states it derives content automatically from page metadata. It distinguishes the tool by the 'no fields to fill in' scope, but it never explicitly contrasts this with the sibling render_og_image, so it stops short of full sibling differentiation.

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 phrase 'for an existing public page with no fields to fill in' supplies the main use condition and the 'Any field can be overridden' note hints at customization. However, no alternative tools are named and there is no guidance about when not to use this tool, leaving the agent to infer the boundary with render_og_image.

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?

With no annotations, the description carries the full burden. It discloses key behavioral traits: credits never expire and it is a one-time PayPal payment, not a subscription. However, it does not describe the return value or any side effects beyond that, leaving some behavioral uncertainty for a simple tool.

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 consists of three concise sentences, each contributing distinct information: the core action, the credit validity, and the payment model. It is front-loaded with the primary purpose and contains no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with no output schema, the description covers the essential purpose and key constraints. It could specify the return format or clarify what a 'credit pack' entails, but given the simplicity, it is largely complete for correct 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?

The tool has zero parameters, so the schema covers everything (100%). The description adds no parameter-specific information, but there is nothing to document; the baseline of 4 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 clearly states the action ('Return') and the resource ('OG Stamp credit packs'). It implicitly differentiates from the image-related siblings by focusing on credits, making the tool's purpose unambiguous.

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 mentions product features (credits never expire, PayPal one-time) but does not situate the tool's use case or explicitly compare with siblings, 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.

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

With no annotations provided, the description carries the full burden of behavior disclosure. It effectively discloses rate limits ('30/IP/day'), authentication needs ('Bearer ogs_…'), production requirements ('store the PNG on your CDN — do not hotlink the free GET URL'), and monetization ('Buy credits'). This goes well beyond a minimal statement and gives the agent actionable operational constraints.

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

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

The main purpose is front-loaded in the first sentence, and the following sentences each add relevant operational details: supported options, free-tier limits, production guidance, and use-case positioning. It is not overly long for 12 parameters and includes practical instructions, though the pricing link could be considered tangential.

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 12 parameters, no annotations, and no output schema, the description is quite complete: it explains what the tool returns (a 1200x630 PNG URL), how to use it in production, rate limits, and an external alternative. The only notable gap is not mentioning the sibling og_image_from_url or explaining when to choose that tool instead, which would fully round out the contextual picture.

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 parameters are already well documented in the schema. The description summarizes key parameter families (title, subtitle, badge, theme, logo_url, hex colors) but does not add meaningful detail beyond what the schema already states. It does reinforce the HTTPS requirement for logo_url and the hex expectation for colors, but that is also present in the schema 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 opens with a specific verb and resource: 'Build a 1200x630 Open Graph PNG URL.' It also lists supported inputs such as title, subtitle, badge, theme, and hex colors, making the tool's purpose clear. It does not explicitly differentiate from the sibling og_image_from_url, though the broader context ('Not a template studio; for title-based branded cards') helps position it.

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 gives explicit usage context: free light use with a 30/IP/day limit, and production usage requiring a POST to https://ogstamp.com/api/og with a Bearer token while discouraging hotlinking. It also states when this tool is appropriate ('for title-based branded cards when you do not want to self-host @vercel/og') and what it is not ('Not a template studio').

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