Skip to main content
Glama

Sellular

by online.sellular
OverviewDiscussionsAdmin

answer_page_targets

Read-onlyIdempotent

Who could publish a page that names this site. Runs answer_engine_gap, then keeps only the slot-holders whose TITLE reads like a third-party roundup ("17 Best X Tools", "X alternatives") rather than a vendor's own landing page, collapses them to one entry per host, and probes /write-for-us, /submit, /contact and /about for a reachable route. Use when a site appears in none of its buyer queries and you want the list of people to ask rather than another page to publish: a comparison page bets that this site gets retrieved, a roundup entry bets that an already-retrieved page names it. Returns evidence (the raw title) on every target, a separate discussions list of threads where a person is ASKING for something like this (community hosts and question-shaped titles, one entry per thread rather than per host, no contact probe because the thread URL is the route), and a skipped list of what both tests rejected, because they ARE heuristics and you must be able to overrule them. Read discussions first when the roundups all sell placement: a thread is a named person with the problem, and it costs nothing to reach. A null contactUrl means those four paths 404ed, not that the site cannot be reached. It does NOT rank by authority and does NOT predict whether a pitch will land; many of these sell placement. Admin token required; it bills per search.

Input Schema

NameRequiredDescriptionDefault
domainYesA domain (example.com) or full URL.
queriesNoUp to 4 buyer queries. Strongly preferred over the category fallback.
refreshNoRe-run the searches instead of using the 7-day cache. Costs billed searches, so only when the cached answer is known stale.
categoryNoOnly used to build fallback queries when `queries` is omitted.
maxHostsNoCap on hosts probed for a contact route (default 10). Ranked by slots first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / refresh
      Added value: +{
+  "description": "Re-run the searches instead of using the 7-day cache. Costs billed searches, so only when the cached answer is known stale.",
+  "type": "boolean"
+}
  2. Added

TDQS

A4.3/5.0
Behavior4/5

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

Goes well beyond the annotations: declares 'Admin token required; it bills per search,' discloses the internal heuristics and their fallibility ('they ARE heuristics and you must be able to overrule them'), and pre-empts a misread of null contactUrl ('means those four paths 404ed, not that the site cannot be reached'). Also sets negative expectations ('does NOT rank by authority and does NOT predict whether a pitch will land'). Fully consistent with readOnlyHint=true — it only searches and probes.

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?

Purpose is front-loaded correctly, but the body is a single dense paragraph that packs return-value detail, heuristic caveats, and strategy advice into long compound sentences. Nearly all content is substantive, yet the structure makes it harder to scan than it needs to be for a tool with four optional parameters.

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?

There is no output schema, and the description compensates fully by naming every returned field (`evidence`, `discussions`, `skipped`, `contactUrl`) and its semantics. Auth, cost, caching implications, and failure modes are all covered, so an agent has everything needed to call it and interpret results correctly.

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%, so the baseline is 3. The description adds only mild extra meaning — that maxHosts governs the contact-route probing and that queries feed the searches — without explaining formats, ordering of `queries`, or when category fallback degrades quality beyond what the schema already says.

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 concrete verb and resource ('Who could publish a page that names this site') and then explains the mechanism: it runs answer_engine_gap, filters to roundup-style slot-holders, dedupes per host, and probes for a contact route. It explicitly distinguishes itself from the alternative deliverable ('the list of people to ask rather than another page to publish'), so an agent can tell it apart from answer_engine_gap or a comparison-page workflow 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?

'Use when a site appears in none of its buyer queries' gives an explicit triggering condition, and the comparison-vs-roundup framing explains why you'd pick this over publishing. It even sequences the consumption of results ('Read `discussions` first when the roundups all sell placement'), which is rare and actionable.

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

All Sellular toolsInspect
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