SMM panel catalog: cheapest services across panels, Trust Scores, reviews, comparisons, panel tools
Scored across 9 tools
Each tool has a clearly distinct role: aggregate stats, panel comparison, single-panel details, market listings, service price lists per panel, cross-panel service search, panel search, tool search, and guide listing. The only potential overlap (list_services vs search_services) is explicitly resolved by scope (one panel vs all panels).
Eight of nine tools follow a consistent verb_noun pattern (list_, get_, compare_, search_). The outlier is catalog_stats, which is a noun phrase, breaking the otherwise uniform convention.
Nine tools are well-scoped for an SMM panel directory and comparison service. Each tool addresses a distinct informational need without redundancy, and the count is neither thin nor excessive.
The surface covers panels, services, markets, tools, guides, and aggregate stats, enabling core research workflows. Minor gaps exist, such as fetching a specific guide or tool by ID, but agents can work around them via listing tools with filters.
How many panels are tracked and online, verified owners, panels with an API, tools, live prices, reviews read, the review platforms.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the scope of data being counted, which is useful transparency about what the response contains, but it says nothing about whether the call is read-only, whether results are cached/stale, rate limits, auth needs, or the shape of the returned values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with the primary metric ('how many panels are tracked and online') placed first, followed by a brief comma-delimited list of the remaining counters. No filler, though the trailing items are loosely phrased ('the review platforms') and slightly less scannable than the opening.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool the description is mostly sufficient, but it leaves the return structure entirely unspecified and the individual counters ambiguous ('reviews read', 'live prices' are not defined). An agent knows roughly what it will get back but not how the metrics are keyed or what units/period they cover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to clarify; baseline for a no-param tool is 4. Schema coverage is trivially 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description make clear this is an aggregate/totals tool for the catalog, and the enumerated metrics (panels online, verified owners, tools, live prices, reviews read) name the specific resource being counted. It implicitly distinguishes itself from the verb-oriented siblings (get_panel, search_panels, list_guides) by being the only counting/summary endpoint, though it never says so explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, no mention of alternatives such as search_panels or list_markets for detail-level data, and no prerequisite or exclusion notes. The only hint of usage is the implied 'call this when you want catalog totals', which the agent must infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Two to five panels side by side: Trust Score, stars and review count, price from, services, order counter, age, verified owner, online status — and the smm.guide page that compares them. Pass slugs or domains.
| Name | Required | Description | Default |
|---|---|---|---|
| panels | Yes | Slugs (prm4u-com) or domains (prm4u.com) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the compared data points and the fact that an smm.guide comparison page is involved, which is useful output context, but says nothing about authentication needs, rate limits, failure behavior for unknown slugs, or whether the call is a pure read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with the cardinality first and the input requirement last. The attribute enumeration is long but earns its place since there is no output schema, though the em-dash list is slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with full schema coverage and no output schema, the description covers the cardinality constraint (matching minItems/maxItems), the accepted identifier formats, and the returned fields, which substitutes well for a missing output schema. Only edge-case/error behavior is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter is already documented as 'Slugs (prm4u-com) or domains (prm4u.com)'. The description's 'Pass slugs or domains' merely restates the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (compare) and resource (panels) with an explicit cardinality ('Two to five panels side by side') and enumerates the exact attributes compared. This makes it clearly distinguishable from the single-panel get_panel and the retrieval-oriented search_panels siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Pass slugs or domains' gives input guidance, and the cardinality implies the compare-multiple use case, but there is no explicit when-to-use/when-not guidance or named alternative such as get_panel for a single panel. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every measured figure for one panel: Trust Score with its parts, stars and the platforms behind them, domain dates, price list summary per network, order counter, online status, links to the listing and the badge. Pass the slug (prm4u-com) or the domain (prm4u.com).
| Name | Required | Description | Default |
|---|---|---|---|
| panel | Yes | Slug or domain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It implicitly frames a read-only detail fetch and does list the data categories returned, which is useful, but it omits error behavior for unknown slug/domain, any auth or rate-limit notes, and whether sections can be absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with what the tool returns and followed by the identifier syntax. The long comma-separated field list is dense but every item is a distinct returned section, so little is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must describe the return payload, and it does so fairly thoroughly (Trust Score parts, stars, domain dates, price list, counters, links). Only edge cases such as not-found behavior are missing for a simple single-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the terse label "Slug or domain", so the baseline is 3. The description goes beyond that by giving concrete format examples for both accepted identifier forms (prm4u-com vs prm4u.com), which meaningfully reduces invocation ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (one SMM panel) and enumerates the measured figures returned, making it clearly the single-panel detail lookup rather than a search. It never explicitly contrasts itself with siblings like search_panels or compare_panels, so sibling differentiation is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Pass the slug (prm4u-com) or the domain (prm4u.com)" tells the agent how to invoke it, but there is no statement of when to use this instead of search_panels or compare_panels, nor what to do when a lookup fails. Usage is implied by the identifier-based framing rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
smm.guide articles: how to choose and compare SMM panels, the most popular panels, starting a panel, payment and earning guides. Optional text filter.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It conveys the content domain and that filtering is optional, but does not disclose read-only status, return format, pagination behavior, or how the limit parameter affects results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that starts with the resource and then lists topics. It is efficient and wastes little space, though the topic list is somewhat dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with no output schema, the description covers the resource content and one parameter. It remains incomplete on usage context, return behavior, and the limit parameter, but provides enough to make a basic call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It adds meaning for the query parameter by calling it an optional text filter, but says nothing about limit; however, limit is a standard constrained integer whose schema default/min/max make its purpose inferable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource (smm.guide articles) and enumerates the topics covered, which clearly distinguishes it from sibling panel/service tools. It does not explicitly state the verb 'list' or 'find' in the description, relying on the name and title for that, but the purpose is still clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to use this tool versus alternatives, nor does it name any siblings such as search_panels or list_services. It only mentions an optional text filter, leaving usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Country and language markets (India, Turkey, Brazil, Russia & CIS, Korea, Thailand, Indonesia, Nigeria, Vietnam, Chinese, Arabic, Spanish), "international" for panels with no local signal, and the "api" market — each with the number of panels online and the rule that puts a panel there.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it does disclose the payload shape: each market comes with the number of panels online and the rule that assigns a panel to it. It is silent on read-only status (safe to assume from a list operation), on ordering, and on total result size, so disclosure is partial rather than complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence that leads with the resource and then the return content, with no filler or repetition. The parenthetical market enumeration is long but earns its place as the only place an agent can learn the valid market identifiers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no annotations, and no output schema, the description is the only source of return-value information, and it does describe what each entry contains (panel count plus routing rule). Missing are ordering, pagination, and error behavior, but for a parameterless enumeration tool the coverage is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which sets the baseline at 4 per the rubric. The enumerated market names in the description are actually output-domain vocabulary rather than inputs, so there is no parameter semantics gap to fill.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (country/language markets) and what it returns (panel counts and the routing rule per market), and even enumerates the market values so an agent knows the taxonomy up front. It does not, however, distinguish itself from sibling list tools such as list_guides or list_services, so an agent must infer the distinction from the name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no mention of prerequisites, and no named alternatives among the siblings (catalog_stats, list_services, search_panels). Usage is only implied — an agent would guess this is for discovering valid market identifiers before filtering other calls, but the description never says so.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The public price list of a panel in US dollars per 1,000, cheapest network first. Filter by network, kind (followers, likes, views, comments, subscribers …) or a text query.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| page | No | ||
| limit | No | ||
| panel | Yes | ||
| query | No | ||
| platform | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that prices are public, denominated in USD per 1,000 units, and pre-sorted cheapest first, which is meaningful invocation context. It omits any mention of authentication requirements, result shape, or how paging behaves across the page/limit params.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, tightly front-loaded: the highest-value semantics (currency, unit, sort order) come first, then the filter facets. There is no filler, though the filter sentence packs three distinct facets into one clause without much structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter read tool with no annotations and no output schema, the description covers the core 'what you get' (public USD/1,000 price list, sorted) but leaves notable gaps: the return shape of a service entry, how pagination interacts with defaults, and the network/platform naming mismatch. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it partly does: it clarifies the 'kind' facet with concrete examples (followers, likes, views) and mentions a text query. But it says 'network' while the schema exposes 'platform', an ambiguous mapping, and it says nothing about page or limit despite both being present with constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource and its semantics: 'the public price list of a panel in US dollars per 1,000, cheapest network first.' An agent can tell this returns a panel's service catalog with prices. It does not explicitly differentiate itself from the similarly named sibling search_services, leaving the list-vs-search distinction implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Filter by network, kind ... or a text query' implies the browsing/enumeration use case and shows the available narrowing options. However, it never states when to prefer this over search_services or search_panels, so the agent must infer the boundary between 'list a panel's catalog' and 'search for a specific service'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find SMM panels in the smm.guide catalog by name or domain, market (country/language or "api"), network with a public price list, engine, verified owner. Returns summaries with Trust Score (0–100), stars, price from, order counter, age. Online panels only unless online_only is false.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | rank | |
| limit | No | ||
| query | No | Name or domain contains | |
| engine | No | ||
| market | No | india, turkey, brazil, russia, korea, thailand, indonesia, nigeria, vietnam, china, arabic, spanish, international or api | |
| platform | No | instagram, tiktok, youtube, telegram, facebook, twitter, spotify … | |
| online_only | No | ||
| verified_only | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it does disclose a non-obvious behavioral default (online panels only unless online_only is false) plus the shape of returned summaries. It omits auth/permission needs, pagination behavior, and rate limits, which leaves meaningful gaps for a 9-param search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with the resource and primary filters front-loaded and no filler. Slightly list-heavy in the middle but every clause maps to a capability or return field.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description compensates by naming the returned summary fields (Trust Score, stars, price from, order counter, age). Combined with the schema-documented page/limit bounds, an agent has enough to invoke it correctly; sort semantics and pagination guidance are the main remaining gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, yet the description expands several params beyond the schema — market accepts country/language values or "api", query matches name or domain, and online_only's default effect is stated. It leaves page, sort, limit, and especially platform (whose meaning is only hinted in the schema) without added context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Find SMM panels in the smm.guide catalog") and enumerates the filterable dimensions (name/domain, market, network, engine, verified owner). An agent can tell this is a discovery/search tool versus get_panel or compare_panels, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the tool is for finding panels, and the final sentence hints at a default-online filter. There is no explicit when-to-use/when-not guidance or routing to siblings like get_panel for detail lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where a service is cheapest across all panels in the catalog: offers of one network and, optionally, one kind (followers, likes, views, comments, subscribers, members, shares, live …), cheapest first, one offer per panel, in US dollars per 1,000, with the panel, its Trust Score and links. Optional filters: only offers with refill, only real-user offers, only non-drop. Use it for questions like "where to buy cheap Instagram followers" or "cheapest Telegram members".
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | followers, likes, views, comments, subscribers, members, shares, live … | |
| limit | No | ||
| platform | Yes | Network key: instagram, tiktok, youtube, telegram, facebook, twitter, spotify, threads … | |
| real_only | No | ||
| refill_only | No | ||
| non_drop_only | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses sorting (cheapest first), deduplication (one offer per panel), normalization (US dollars per 1,000), and returned fields (panel, Trust Score, links). It omits auth/rate-limit or result-count behavior and never explicitly states this is a read-only lookup, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense, front-loaded sentence carries the operation, aggregation semantics, and output shape, followed by a short usage sentence. Every clause adds information, though the first sentence is long enough that it reads as slightly packed rather than crisp.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with no annotations and no output schema, the description covers return content, ordering, currency normalization, and all optional filters. The remaining gap is the 'limit' parameter's default and cap, which the agent must read from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description must compensate, and it does: it enumerates valid 'kind' values (followers, likes, views, comments, subscribers, members, shares, live) and explains the three boolean filters (refill, real-user, non-drop). It does not clarify the 'limit' parameter (default 5, max 10) or the platform key vocabulary beyond what the schema already gives.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation on a specific resource: finding the cheapest offers of one service across all panels in the catalog, with the aggregation rules (one offer per panel, cheapest first). It is clearly distinguishable from siblings like list_services (all services) and search_panels (panels, not offers). An agent can select it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete invocation contexts ('where to buy cheap Instagram followers', 'cheapest Telegram members'), which is strong positive guidance. It does not, however, name a competing sibling or state when NOT to use it (e.g., vs list_services for browsing), so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools for starting and running an SMM panel business: panel scripts (software), payment gateways, hosting, domain registrars, SMS verification, proxies, VPN and engagement platforms — each with Trust Score, reviews and a link. Filter by category and name.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Name or domain contains | |
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses return content — each result carries a Trust Score, reviews, and a link — but says nothing about rate limits, pagination behavior, auth needs, or result ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the resource scope followed by the filter mechanism. The category enumeration is dense but each item earns its place by defining coverage; nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-param search tool with no output schema and no annotations, the description covers what it searches, what it returns, and how to filter. The remaining gap — pagination via 'limit' and result ordering — is minor for a discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only 'query' is documented in-schema), so the description is expected to compensate. 'Filter by category and name' does clarify the two filter fields, but the limit/pagination parameter is never addressed and no match semantics (exact vs contains) are added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb (search/filter) and a specific, enumerated resource — panel scripts, payment gateways, hosting, domain registrars, SMS verification, proxies, VPN, engagement platforms — which cleanly delineates it from the panel- and service-specific siblings. No explicit naming of those siblings, but the enumeration makes the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the category list and the closing 'Filter by category and name,' so an agent can infer when to reach for this tool over search_panels/search_services. There is no explicit when-not or named alternative, leaving the routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
catalog_statscompare_panelsget_panellist_guideslist_marketslist_servicessearch_panelssearch_servicessearch_toolsDiscover, compare and buy social media growth for Instagram, TikTok, YouTube, Telegram, X and more
White-label reseller platform: eSIM, VPN, SMM, AI tools, CRM, hosting. Prices, clients and orders.
Ad marketplace: search Telegram/VK/Max channels by topic, geo, price; reach, ER, CPV stats.
Public Instagram and YouTube data for AI agents: reels, videos, channels, comments. Pay per result.
Add one secure layer between your agents and this server.
