Skip to main content
Glama
zai-one

telegram-ads-mcp

by zai-one

Validate ad post

check_ad_post
Read-onlyIdempotent

Validate a promotion URL and post text before creating or launching Telegram Ads. Returns ok or the platform error.

Instructions

Validate promote_url and text before create or launch. Use before launch_ad/create_ad. Read-only. Returns ok or the platform error text.

Input Schema

NameRequiredDescriptionDefault
textNo
promote_urlYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description still adds the return contract ('ok or the platform error text') and reinforces the read-only dry-run nature. It doesn't say what happens on failure (throw vs. error string) or whether it hits the live platform, which openWorldHint implies.

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?

Three short sentences, front-loaded with the action and ordering constraint. Almost nothing is wasted; only 'Read-only' partly restates the annotation.

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?

With an output schema present, return values needn't be fully documented, and the description covers purpose, timing, and side-effect profile. The only gap is failure semantics and whether validation is a live platform call or local lint, which matters for an openWorld tool.

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 0%, so the description must compensate. It names both parameters, which is more than the schema title alone, but adds no semantic detail such as format, constraints, or what 'text' length/type is expected. Naming without meaning earns a mid-range score.

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?

States a specific verb+resource ('Validate promote_url and text') and names the exact fields being validated. It clearly separates itself from the mutation siblings create_ad and launch_ad, which it complements rather than duplicates.

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?

Gives an explicit trigger ('Use before launch_ad/create_ad'), which is precisely when this pre-flight check matters. It does not address when to skip it or clarify its relationship to the similarly named preview_ad, but the core usage context is unambiguous.

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