Skip to main content
Glama

Adako: Google Ads, Meta Ads & Linkedin Ads MCP

Check an image or video before it becomes an ad

check_media
Read-onlyIdempotent

🟢 READ-ONLY — runs immediately, changes nothing. Cost: free (not counted against tasks).

Checks a creative file before any ad is built from it, and answers where a file with no link yet has to go. Use when: the user offers an image or a video in any form — a link, a file on their computer, "the one from our site" — and always before a create tool that takes image_url or video_url. What it does: repairs the share links that do not serve files (Drive, Dropbox, OneDrive, GitHub, Imgur have a direct form), fetches only the head of the file to read its type, size, dimensions and an MP4's duration, and reports slot by slot which platforms accept it and what would be cropped. Call it with no arguments when the user has a file but no link: it returns the three ways to get one, cheapest first, starting with reusing what is already in their ad account. Adako hosts nothing and never receives the file. The platform downloads the URL itself, from its own servers and often hours later, which is why a local path, a login-gated page or a link that expires cannot work however it is passed. Free, instant, touches no ad account and creates nothing, so run it as often as needed. If a file is refused, say exactly which rule it broke and what to change — never retry a create with the same file.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoOnly judge image slots or video slots. Defaults to what the file turns out to be.
urlsNoThe file links to check, as the user gave them — share pages and http links are repaired rather than rejected. Leave this out to get the "where do I put my file" answer instead.
raw_dataNoReturn compact JSON only (no markdown). Use when you will compute on the result.
platformsNoOnly judge these platforms. Defaults to all five, which is what to use when the user has not chosen yet.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly/idempotent/non-destructive), and the description adds substantial context beyond them: cost is free and not counted against tasks, it repairs share links (Drive/Dropbox/etc.), fetches only the head of the file, Adako hosts nothing and the platform downloads the URL later, and local paths/login-gated/expiring links cannot work. This is genuinely useful behavioral disclosure.

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

Conciseness4/5

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

Front-loads the read-only/cost facts and organizes into clear labeled sections. Slightly verbose with some repetition (free/read-only/creates-nothing restated across sentences), but nearly every sentence earns its place.

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

Completeness5/5

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

For a zero-required-param, four-parameter tool with no output schema, the description covers invocation modes, defaults, hosting semantics, and retry guidance. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds the no-argument behavior (returns the three cheapest ways to obtain a link) and reinforces the repair-not-reject semantics, though the platform default behavior is largely duplicated from the schema. Marginal but real added value.

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 (checks) and resource (a creative file — image or video) with explicit scope ('before any ad is built from it'). An agent can immediately distinguish it from the create tools and platform siblings that take image_url/video_url.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use: 'the user offers an image or a video in any form... and always before a create tool that takes image_url or video_url.' It also names the no-argument invocation case ('when the user has a file but no link') and routes refusal handling ('never retry a create with the same file').

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.