GrowVib - Social Media Growth

search_catalog

Read-onlyIdempotent

START HERE when you do not yet know which service to buy: this is the entry point to the catalog. Already have a service id? get_service returns that one in full detail. Know the service and only need the right plan for a quantity? recommend_service picks one. Searches the sellable social growth service catalog (Telegram, Instagram, TikTok, YouTube and more). Each result includes the service (id, name, platform, starting/cheapest price per 1000) AND up to 8 of its plan options (the recommended and cheapest ones, each with id, name, price per 1000, min/max quantity; options_total says how many there are and get_service returns them all) - present the options to the user and let them choose a plan, then pass that service_option_id to get_quote and create_paid_order (this endpoint lists it while the accountless x402 payment channel is on), or create_checkout when a person will pay in their own wallet instead (listed while checkout sessions are on) instead of defaulting to the cheapest.

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": "search_catalog"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Max results per page (1-50, default 50).
`query`	No	Keyword search over service names and descriptions. Pass concrete keywords (e.g. "telegram members"); map the user's natural-language intent (budget, country, speed) onto the structured filters below.
`locale`	No	Catalog language for names/descriptions (default en). Each service is returned once per call in this single language.
`offset`	No	Row offset for paging (default 0). The response returns total, limit, offset and returned; fetch the next page with offset += limit while offset+returned < total.
`country`	No	Filter to geo-targeted services for a country (matches the catalog's geo-target codes, e.g. a country name or code). Most services are global and unaffected.
`sort_by`	No	Sort order: "newest" (default) or "name" (alphabetical).
`platform`	No	Filter by platform key, e.g. telegram, instagram, tiktok, youtube.
`quantity`	No	Optional: only list the options that accept this quantity (min_quantity <= quantity <= max_quantity). options_total still counts every option and options_fit says how many accept it. Each service still shows at most 8 options (the recommended ones first, then the cheapest; options_truncated says when some were cut), so call get_service for the full list of a service you have chosen.
`max_price`	No	Only services whose starting price per 1000 is at most this (USD) - use for a budget cap.
`min_price`	No	Only services whose starting price per 1000 is at least this (USD).
`sort_order`	No	"asc" or "desc". Defaults to desc for newest, asc for name.
`speed_tier`	No	Filter by delivery speed tier (e.g. instant, fast) - use for "fastest delivery" requests.
`quality_tier`	No	Filter by quality tier, e.g. standard, premium.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 10, 2026

changedInput schema / properties / quantity / description

Previous value: -"Optional: only list the options that accept this quantity (min_quantity <= quantity <= max_quantity), cheapest first. options_total still counts every option and options_fit says how many accept it, so a small buyer finds its orderable options without paging through hundreds."New value: +"Optional: only list the options that accept this quantity (min_quantity <= quantity <= max_quantity). options_total still counts every option and options_fit says how many accept it. Each service still shows at most 8 options (the recommended ones first, then the cheapest; options_truncated says when some were cut), so call get_service for the full list of a service you have chosen."

Changed1 schema field changedNov 9, 2026

addedInput schema / properties / quantity

Added value: +{
+  "description": "Optional: only list the options that accept this quantity (min_quantity <= quantity <= max_quantity), cheapest first. options_total still counts every option and options_fit says how many accept it, so a small buyer finds its orderable options without paging through hundreds.",
+  "type": "number"
+}

Changed1 schema field changedNov 7, 2026

changedInput schema / properties / limit / description

Previous value: -"Max results per page (1-50, default 20)."New value: +"Max results per page (1-50, default 50)."

First observedSep 10, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare this a safe, idempotent, closed-world read, so the description correctly spends its words elsewhere: it discloses the shape of each result (service plus up to 8 plan options, recommended then cheapest, with options_total/options_truncated flags) and the follow-on payment paths. That is real context beyond the annotations, though the parentheticals about the x402 channel and checkout sessions being 'on' are vague and never explain what happens when they are off.

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

Conciseness3/5

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

The opening is well front-loaded and the sibling routing is crisp, but the final third collapses into one long run-on sentence with nested parentheticals about x402 and checkout sessions that is hard to parse. It is information-dense rather than padded, but the structure degrades exactly where the workflow instructions matter most.

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

Completeness4/5

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

For a 13-parameter tool with no output schema, the description does the heavy lifting by describing the result payload and option truncation, which the agent would otherwise have to discover by calling. Completeness is only slightly undercut by the ambiguous conditional wording around the two payment channels.

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 description coverage is 100% and the 13 parameters are documented thoroughly in the schema itself, including paging arithmetic and the quantity/options_fit behavior, so the baseline of 3 applies. The description adds only a routing hint (map natural-language budget/country/speed intent onto structured filters) rather than any new per-parameter semantics.

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 ('Searches the sellable social growth service catalog') and explicitly frames itself as the entry point when the service is unknown. It names the two siblings it is not (get_service for a known id, recommend_service for a plan for a quantity), so an agent can distinguish all three without opening a schema.

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?

Gives an explicit trigger ('START HERE when you do not yet know which service to buy'), an explicit exclusion (skip it if you already have a service id), and a concrete alternative for the adjacent case ('Know the service and only need the right plan for a quantity? recommend_service picks one'). It even routes downstream of itself, telling the agent to have the user pick a plan and then pass service_option_id to get_quote/create_paid_order, or create_checkout when a human pays from their own wallet.

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

All GrowVib - Social Media Growth 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?