Tokfluence

Run an Ultra Search from a brief

start_ultra_search

Hands a brief to Ultra Search, which does the whole job on our side: it reads the brief, searches the index, crawls TikTok for creators we do not have yet, and has a model judge every candidate against the brief. The result is a ranked creator list on the user's account, each creator with a tier (bullseye, adjacent, craft), a 0 to 100 fit and a one-sentence reason.

Use it when the user wants a finished list for a brief, rather than to browse the index with search_creators. It takes from a few minutes to a few hours; poll get_ultra_search with the id this returns.

Write the brief as the user would: who the creators are, what they post about, and where, in one or two sentences. Words like "ideally" or "bonus if" rank creators; they never filter. A brief that asks for one account or link, or names no topic, is refused with suggestions and nothing is spent.

IT SPENDS ONE OF THE USER'S ULTRA SEARCHES, SO IT IS TWO STEPS.

Call it first without confirm. Nothing is started: you get back how many Ultra Searches they have left this period. Tell the user, and wait for a clear yes. Only then call again with confirm: true and the same arguments. It costs no API credits. One Ultra Search runs at a time per account.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "brief": "<brief>"
    },
    "name": "start_ultra_search"
  }
}

Input Schema

Name	Required	Description
`ref`	No	Reseller keys only (required there): an opaque 16-128 character id ([A-Za-z0-9_-]) of the caller this search is for. Pass it again to get_ultra_search.
`brief`	Yes	Who to find, in the user's words, up to 500 characters.
`confirm`	No	Set only after the user has seen what it spends and said yes. Omit on the first call.
`min_fit`	No	With ref: the fit (0-100, default 50) a creator must reach to count. A finished search with nobody there is free.
`language`	No	ISO 639-1 code the creators post in, e.g. 'en'.
`countries`	No	ISO-3166 alpha-2 codes the creators must be in, e.g. ['GB', 'IE']. Omit to use any countries the brief names.
`max_followers`	No	Largest follower count.
`min_followers`	No	Smallest follower count. Omit to read it from the brief, if it says one.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations flag a non-readonly, non-idempotent, open-world operation, and the description adds the critical context they cannot: it consumes one Ultra Search from the user's quota, costs no API credits, runs asynchronously for minutes to hours, and allows only one at a time per account. The mandatory two-step confirm handshake (first call starts nothing, second call with confirm:true executes) is a major behavioral trait disclosed only here. It stops short of detailing what happens to an in-flight search if the user re-calls or how failures are reported.

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

Conciseness4/5

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

Well front-loaded — purpose first, then when-to-use, then brief-writing guidance, then the cost/confirm mechanics. Nearly every sentence carries actionable information, though the confirmation flow is restated two or three times (capitalized warning, step description, and closing constraint), which is slightly redundant even for a costly operation.

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 an 8-parameter, quota-consuming asynchronous tool with no output schema, the description covers the result format, the confirm-response behavior, polling, per-account concurrency, and refusal semantics. An agent has everything needed to call it correctly and safely on the first attempt.

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, but the description adds real semantic guidance for the highest-risk parameter: how to phrase the brief, that soft-preference words rank rather than filter, and what kinds of briefs are rejected. It also explains the confirm double-call protocol. It leaves min_fit and the ref/reseller flow to the schema, which is acceptable given full coverage.

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 names a specific verb and resource and spells out the full pipeline (reads brief, searches index, crawls TikTok, model-judges candidates) plus the concrete output shape (ranked list with tier, 0-100 fit, reason). It explicitly contrasts with the sibling search_creators, so an agent can route between them without opening either 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 when-to-use rule ('when the user wants a finished list for a brief, rather than to browse the index with search_creators'), the expected duration, and the polling follow-up via get_ultra_search. It also states refusal conditions (one account/link, or no topic) and that 'ideally'/'bonus if' rank rather than filter, which shapes how the argument should be written.

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

All Tokfluence 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.