Skip to main content
Glama

ProductClank

by com.productclank

Boost a social post

boost_post

Rally the ProductClank community to engage with a specific social post. Creates a boost campaign and spends the user's credits: 'replies' generates 10 AI reply drafts (200 credits); 'likes' (30 likes) and 'repost' (10 reposts) cost 300. Supports Twitter/X, Instagram, TikTok, LinkedIn, Reddit, Farcaster, and YouTube (replies + likes on YouTube; reposts only on X and Farcaster) — the platform is auto-detected from the URL. product_id is OPTIONAL: link a product (from search_products or create_product) to tailor replies with the product name, or omit it for a tweet-first boost that uses generic amplification language. Confirm the action and its credit cost with the user before calling.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
post_urlYesFull URL of the post to boost (any supported platform)
product_idNoOptional product UUID (from search_products or create_product). Omit for a tweet-first boost.
action_typeNoHow the community engages. Default: replies. Reposts are Twitter/Farcaster only.
reply_guidelinesNoOptional guidance for the tone and content of community replies

TDQS

A4.7/5.0
Behavior5/5

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

It discloses that the tool creates a campaign, spends credits, auto-detects platform from URL, and lists platform-specific capabilities such as YouTube replies plus likes and reposts only on X/Farcaster. It also instructs the agent to confirm the action and credit cost with the user, adding meaningful behavior beyond the annotations.

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?

The description is dense but every sentence contributes: core purpose, credit costs, platform constraints, product_id decision, and required user confirmation. It is well-organized and front-loaded with the primary outcome before moving to details.

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 tool with four parameters, platform-specific behavior, credit costs, and a potentially costly side effect, this description is exceptionally complete. It tells the agent exactly what will happen, what each action costs, where it is supported, how to tailor replies, and what to confirm with the user before invoking.

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 enriches the parameters: it quantifies credits per action, clarifies platform support per action_type, and explains the optional product_id behavior with product-linked tailoring versus generic tweet-first language. This is meaningful added guidance.

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 specific verb-plus-resource statement: 'Rally the ProductClank community to engage with a specific social post.' It clearly distinguishes boosting a post from broader campaign tools by detailing exact engagement types and credit costs.

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?

The description gives clear operational context: when to use the tool, supported platforms, action_type choices, and when to include or omit product_id. It does not explicitly contrast this tool with sibling alternatives like create_campaign or create_content_campaign, but the use case is clearly implied.

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