preview_adRender a sponsored-message preview as a PNG to review Telegram Ads copy before launch or diagnose issues; saves under ./previews and returns the image.
Render a sponsored-message preview PNG and save it under ./previews (gitignored). Use to show the user the copy before launch or during diagnosis. Returns an image.
| Name | Required | Description | Default |
|---|---|---|---|
| ad_id | Yes |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds key behavioral context beyond annotations: the file output path './previews (gitignored)' and an explicit statement that it returns an image. Annotations already cover the safety profile (readOnly, idempotent, openWorld), so this description fills the gaps about what the tool does with the output.
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?
Three sentences, no waste. Front-loads the primary action, then usage context, then return type. Every sentence 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?
Given the simplicity (1 required parameter, no output schema), the description is complete enough. It covers purpose, usage, and output. The only gap is how to obtain 'ad_id', which is minor but leaves a small hole.
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 0%, so the description must compensate. It doesn't explain what 'ad_id' refers to or how to obtain it (e.g., from get_ads). The only parameter is effectively undocumented, leaving the agent to infer its source. Baseline 3 for one parameter, but with no added semantic value.
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?
States a specific verb+resource: 'Render a sponsored-message preview PNG'. This clearly distinguishes it from get_ad (retrieves data) and create_ad (creates). The specific output format (PNG) adds helpful precision.
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?
Explicitly states when to use: 'to show the user the copy before launch or during diagnosis'. It doesn't name alternatives like get_ad, but the use context is clear enough for an agent to select this tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.