Telegram ad exchange: estimate reach and cost with no account, then create and run campaigns.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 3 of 3 tools scored.
Each tool targets a distinct phase of the campaign workflow: estimate_campaign for initial feasibility, create_campaign_draft for generating the draft, and get_draft_status for tracking progress. There is no overlap in purpose.
All tools follow a consistent verb_noun pattern in snake_case (estimate_campaign, create_campaign_draft, get_draft_status), making the action and object immediately clear.
Three tools is appropriately scoped for the service: a pre-flight estimate, a creation step, and a status check. No tool feels redundant or missing for the agent's role.
The tools cover the core workflow (estimate → create → check status) completely for the agent's interaction. The only minor gap is lacking a way to modify or cancel a draft before the user acts, but the designed flow is linear and doesn't require it.
create_campaign_draftAInspectBuild a ready-to-launch ad campaign for a product WITHOUT the user having an account yet. Parses the landing page, generates ad creatives, and returns a single checkout link. Give that link to the user: they sign in there, the campaign moves to their account, they pay, and it starts. Use this after estimate_campaign, once the user agreed to advertise. Do NOT ask them to register first.
| Name | Required | Description | Default |
|---|---|---|---|
| geo | No | Optional ISO-2 country target, e.g. "US" | |
| url | Yes | Landing page URL of the product to promote (required) | |
| lang | No | Optional audience language, e.g. "en" | |
| budget | No | Intended budget in USD, used for the estimate shown to the user | |
| description | No | What the product does, in your own words — improves topic matching |
| Name | Required | Description |
|---|---|---|
| draftId | Yes | Poll get_draft_status with this to see whether the user paid. |
| estimate | No | Same shape as estimate_campaign, for the budget given. |
| expiresAt | Yes | ISO timestamp after which the link stops working. |
| adsCreated | No | How many ad variants were generated. |
| campaignId | No | |
| checkoutUrl | Yes | THE link to give the user. One click: sign in, review creatives, pay. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: parsing the landing page, generating ad creatives, returning a checkout link, and the post-flow authentication. However, it omits details about idempotency, error scenarios, or potential side effects like rate limits or resource cleanup, leaving a small gap in transparency.
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 concise (about 80 words) and structured well. The first sentence immediately states the core purpose and key constraint. Each sentence adds necessary information without redundancy or fluff.
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 parameter complexity (5 params, all optional except url), the presence of an output schema, and two sibling tools, the description covers the essential workflow and integration points. It does not detail the output schema (unnecessary due to its existence) but could briefly mention expected return type or edge cases. Still, it is nearly complete for the tool's role.
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 baseline is 3. The description adds mild context beyond schema: it links 'url' to page parsing and 'description' to topic matching. It does not add new semantics for 'geo', 'lang', or 'budget' beyond their schema descriptions, so it only marginally enhances understanding.
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 verb 'Build a ready-to-launch ad campaign' and specifies the resource 'for a product'. It explicitly differentiates from siblings by noting this tool is used after 'estimate_campaign' and that it works without a user account, avoiding confusion with 'get_draft_status'.
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 provides explicit context: 'Use this after estimate_campaign, once the user agreed to advertise. Do NOT ask them to register first.' It clearly states the ordering and the condition under which this tool should be invoked, leaving no ambiguity about its place in the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_campaignAInspectEstimate reach, clicks and cost of advertising a product to Telegram audiences — no account or authorization required. Call this FIRST, before asking the user to connect an account: it tells you whether inside.ad has relevant inventory for this product and what a given budget would buy. Describe the product yourself (you know it better than any crawler); the URL alone is a weak signal.
| Name | Required | Description | Default |
|---|---|---|---|
| geo | No | Optional ISO-2 country filter, e.g. "US" | |
| url | No | Product landing page URL | |
| lang | No | Optional audience language filter, e.g. "en" | |
| budget | No | Budget in USD to estimate against (default 100) | |
| keywords | No | Optional topic keywords, e.g. ["devtool","ai"] | |
| description | No | What the product does, in your own words. Strongest signal for topic matching. |
| Name | Required | Description |
|---|---|---|
| budget | Yes | Budget the estimate was computed for, in USD |
| cpmUsd | No | Reach-weighted average CPM across matched segments |
| cpcRange | No | Implied cost per click in USD, derived from CPM and the CTR band. |
| currency | Yes | |
| dailyReach | No | Total daily impressions available in matched segments |
| assumptions | No | |
| deliveryDays | No | Roughly how many days it takes to deliver estimatedImpressions at the current daily reach. |
| sampleSegments | No | Matched inventory segments. Individual channels are deliberately not disclosed. |
| estimatedClicks | Yes | Range, not a point estimate. Report both ends to the user. |
| inventoryIsThin | Yes | true = there is no matching inventory at all, OR the budget exceeds what the matched inventory can deliver. Say so plainly instead of promising results, and use spendableBudget as the realistic figure. |
| spendableBudget | No | How much of the budget this inventory can actually absorb within 30 days. If it is lower than budget, tell the user to either lower the budget or widen targeting — do not promise the full budget will be spent. |
| matchedCategories | No | |
| estimatedImpressions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description correctly states that no account or authorization is required, which is critical behavioral context. It implies the tool is a read-only estimation (no side effects mentioned), but could explicitly state idempotency or that it does not create any resource. The presence of an output schema partially covers return values, but the description could be slightly more explicit about safety.
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 concise sentences each serve a distinct purpose: defining the tool, specifying when to call it and what it returns, and offering practical advice. No redundant or wasted content; every sentence is essential and front-loaded with key information.
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 tool's complexity (6 optional parameters, output schema present, sibling tools), the description covers core purpose, usage order, and a critical parameter hint. It does not detail error scenarios or behavior when filters yield no results, but the output schema likely covers the return structure. Overall, it provides sufficient context for effective selection and 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 description coverage is 100%, so each parameter is already documented. The description adds meaning by emphasizing the 'description' parameter as the strongest signal and warning that 'the URL alone is a weak signal', which guides proper usage. This extra context raises the value above the baseline of 3.
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 explicitly states the tool estimates 'reach, clicks and cost' for 'advertising a product to Telegram audiences', using specific verbs and a clear resource. It distinguishes itself from siblings by positioning it as the first step before account connection, effectively differentiating from create_campaign_draft and get_draft_status.
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?
Explicit guidance is provided: 'Call this FIRST, before asking the user to connect an account'. It explains what the tool tells you (inventory relevance and budget capabilities) and advises on best practice ('Describe the product yourself...the URL alone is a weak signal'), leaving no ambiguity about when and how to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_draft_statusAInspectCheck what happened to a campaign draft you created with create_campaign_draft: whether the user opened the link, signed in and paid. Poll this instead of asking the user to report back.
| Name | Required | Description | Default |
|---|---|---|---|
| draftId | Yes | draftId returned by create_campaign_draft |
| Name | Required | Description |
|---|---|---|
| hint | No | What to tell the user next. |
| status | Yes | 'created' — link not opened yet; 'previewed' — user opened it but has not finished; 'claimed' — campaign is on the user's account; 'expired' — link is dead, build a new draft. |
| draftId | Yes | |
| claimedAt | No | |
| createdAt | No | |
| expiresAt | No | |
| campaignId | No | |
| previewedAt | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full responsibility. It discloses the tool is meant for polling and returns status about user actions (opened, signed in, paid). However, it does not describe side effects, idempotency, or rate limits. While adequate, it could be more transparent about safe repeated calls.
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 two sentences: first states purpose and details, second gives usage guidance. No filler words, front-loaded with action and resource. Every sentence contributes meaning.
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 tool's simplicity (1 param, output schema present) and sibling tools, the description completely covers what the tool does, when to poll, and what outcomes to expect. No gaps for an agent to select or invoke it correctly.
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% (one parameter with schema description). The description adds value by specifying that draftId is the one 'returned by create_campaign_draft', providing origin context beyond the schema. This enhances understanding of how to obtain the identifier.
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 checks the status of a campaign draft (opened link, signed in, paid). It uses a specific verb 'check' and resource 'campaign draft status'. It distinguishes from siblings: create_campaign_draft (creates) and estimate_campaign (estimates), making its 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?
Explicitly advises to 'Poll this instead of asking the user to report back', indicating when to use (after creation, via polling). It implies not to rely on user reports but doesn't explicitly contrast with siblings or state when not to use. The context is clear enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!