Skip to main content
Glama

ProductClank

by com.productclank

Put discovery on a schedule

set_campaign_schedule

Turn standing discovery on or off for a campaign. Calling this is free, but switching it ON authorizes spend that happens LATER and unattended: an hourly job runs discovery on its own and bills the user 12 credits per post it finds, with nobody in the loop. So there are two steps and you must not skip the first. STEP 1 — call with enabled:true and NO confirmed flag: nothing is changed and you get back the projected daily and monthly cost, the balance, and how many days of runway that is. STEP 2 — show the user those numbers, get a real yes, then call again with confirmed:true. Never send confirmed:true on your own initiative, on an assumption, or because the user said something general like 'keep it going' — the user has to have seen a number. Turning it OFF (enabled:false) is always safe and needs no confirmation; do it whenever the user asks to stop. Limits on this path are deliberately lower than the website's: up to 4 runs/day, up to 20 posts/run, and never more than 600 projected credits/day. Read the current schedule with get_campaign.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
enabledYestrue starts standing discovery, false stops it
confirmedNoSet true ONLY after the user has seen the projected cost from a previous call and explicitly agreed to it. Omit on the first call — that is what produces the projection.
campaign_idYes
posts_per_runNoTarget posts per run (1-20). Defaults to the campaign's current setting, else 5. Each post found bills 12 credits.
frequency_per_dayNoDiscovery runs per day (1-4). Defaults to the campaign's current setting, else 1.

TDQS

A5/5.0
Behavior5/5

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

The description highlights critical unattended behavior: enabling is free but authorizes later hourly job spend at 12 credits per post discovered. It explicitly warns that costs happen outside the call and without user presence, explains the safety of the off path, and gives concrete operational limits (4 runs/day, 20 posts/run, 600 credits/day) — all material that annotations do not convey.

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?

Although fairly long, every section earns its place: the warning is front-loaded, steps are numbered, and exclusions/limits are grouped logically. The text is dense with high-value guidance and avoids unrelated filler, so its length is justified by the safety-critical nature.

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?

The description covers the invocation flow, expected first-call outputs, user-confirmation requirements, safety thresholds, cost implications, and how to read the current schedule. Given there is no output schema, the description provides enough detail for full correct invocation without leaving a necessary gap.

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

Parameters5/5

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

The description goes far beyond the input schema by explaining the confirmed flag's intentional flow and the meaning of an omitted confirmed flag. It also connects posts_per_run and frequency_per_day to real costs and spending limits, and clarifies that enabled:false requires no confirmation, adding behavioral context the schema cannot express.

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?

The description opens with a precise, action-oriented statement: 'Turn standing discovery on or off for a campaign.' It clearly names the resource and the two possible operations, and it is fully distinguishable from sibling tools like get_campaign by referencing the read operation at the end.

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?

The description provides an explicit, step-by-step usage protocol: call with enabled:true and no confirmed flag first, show the user the projected costs, get explicit agreement, then call again with confirmed:true. It also clearly states when confirmation is never allowed and when enabled:false is safe, giving the agent clear decision rules.

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

All ProductClank toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation4/5

Most tools map cleanly to a distinct resource and action: campaigns, posts, products, research, content spaces, and submissions. A few pairs are close—`create_campaign` vs `create_content_campaign` and `check_balance` vs `get_earnings`—but the detailed descriptions make the intended selection clear.

Naming Consistency4/5

The set largely follows a consistent `verb_noun` snake_case pattern (`list_campaigns`, `generate_posts`, `update_campaign`, `submit_participation`). Minor deviations keep it from a perfect score: `credit_history` lacks a verb, and `create_campaign` reads as generic next to the more specific `create_content_campaign`.

Tool Count3/5

30 tools is high and makes the server feel heavy, but the domain genuinely spans products, credits, campaigns, research, post discovery, content spaces, boosts, and participation rewards. The breadth mostly earns the count, though it sits on the wrong side of the typical 3–15 range.

Completeness4/5

The core end-to-end workflow is covered: create and configure campaigns, discover and refine posts, run research, find opportunities, submit work, and measure results. Gaps exist but are minor for the central purpose—product listings can’t be updated or deleted, and delegates can be added but not removed.

Resources