flayr

Check a CTA before an ad

cta_check

Read-onlyIdempotent

[read-only] Checks whether a draft, post or link points at the brand's goal page (the same check the ad and boost routes run in paid mode; a block there refuses the ad). Run it before every boost or ad and paste the result. Nothing stored, free. Needs the Pro plan or higher. (Wraps POST /api/v2/cta-check.)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "cta_check"
  }
}

Input Schema

Name	Required	Description
`mode`	No	Default: paid.
`postId`	No	A post id.
`brandId`	No	A brand id from GET /api/v2/brands. Required for an account-wide key; a brand-bound key may omit it.
`caption`	No	The caption, when it differs from the draft.
`linkUrl`	No	The link the ad or post would use.
`adButton`	No	The ad button, e.g. LEARN_MORE.
`contentId`	No	A draft id.
`objective`	No	The ad objective, e.g. traffic, link_clicks, engagement. Click objectives can block; others warn.
`platforms`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4/5.0

Behavior4/5

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

Adds real behavior beyond the annotations: entitlement gating (Pro plan or higher), no side effects ('Nothing stored, free'), and the semantics that paid mode is what the ad/boost routes actually enforce. The REST wrapping note helps an agent map behavior to the API. It does not describe the shape of the verdict returned, which matters because there is no output schema.

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?

A single front-loaded paragraph where the read-only marker and the core check come first, followed by operational notes. The parenthetical API wrapper is slightly incidental but still earns some value for agents tracing REST behavior.

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

Completeness3/5

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

For a nine-parameter tool with zero required parameters and no output schema, the description leaves two important gaps: which inputs must be supplied together, and what the returned verdict looks like. Entitlement and side-effect behavior are covered well, so the definition is usable but not self-sufficient.

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 coverage is 89% and the per-parameter descriptions already explain postId, brandId, objective and linkUrl semantics, so the description need not repeat them. The description's only added signal is an implicit hint about paid mode; for nine optional parameters it does not explain which combination constitutes a valid call (draft vs post vs bare link).

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 and resource ('Checks whether a draft, post or link points at the brand's goal page') plus the operational meaning of the outcome: a block refuses the ad. That is enough for an agent to separate this validation check from siblings like ctas_list, ctas_create and cta_settings_get.

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 a clear trigger ('Run it before every boost or ad') and a follow-up action ('paste the result'), which is stronger than most siblings. It does not name alternatives or say when the check can be skipped (e.g., relative to ads_readiness), so it falls short of a full when/when-not/alternative statement.

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

All flayr tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?