Skip to main content
Glama
Sign In

Tokfluence

by com.tokfluence
OverviewDiscussionsAdmin

Check an Ultra Search and read its list

get_ultra_search
Read-onlyIdempotent

Where an Ultra Search is (stage, an estimate of the time left, counts) and, once its list exists, one page of it: the creators best first, each with the judge's tier (bullseye, adjacent, craft), a 0 to 100 fit, a one-sentence reason, a quote of the creator's own bio or caption that shows it (evidence, with the post's URL), who their audience is (audience_type), whether it is a near miss, whether its country was confirmed, how sure we are of it and from which sign (country_confidence, country_signal), and the platform.

Pass min_fit to keep creators with fit at least that, and top_n to keep the best that many of those. Without them you get the whole list. A creator nobody scored passes only min_fit 0.

Omit search_id to read the newest search on the account.

While results_ready is false there is no list yet: wait a few minutes and call again. The list can still grow after the stage reads done while crawl.running is true. A failed search says why in error.

Free.

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

Input Schema

NameRequiredDescriptionDefault
refNoThe ref the search was started with, if any. Required to read a search started with one.
pageNoPage of the list, from 1. Default 1.
top_nNoKeep the best this many after min_fit, 1-1000. Omit for no cut.
min_fitNoKeep creators with fit at least this, 0-100. Omit for no cut.
per_pageNoCreators per page, 1-100. Default 50.
search_idNoId returned by start_ultra_search. Omit for the newest search.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the supplied readOnly/idempotent/non-destructive annotations, it discloses the asynchronous lifecycle (no list until results_ready), eventual consistency (list grows after stage reads done while crawl.running is true), failure signaling via `error`, polling latency ('wait a few minutes'), and cost ('Free'). Those are exactly the traits an agent cannot infer from annotations.

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?

Purpose is front-loaded in the first clause, and the filtering, default-search, and polling rules each occupy a distinct sentence. The opening sentence is a dense run-on with nested parentheticals that taxes scanning, but with no output schema the field enumeration is load-bearing rather than filler.

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?

With no output schema, the description carries the full burden of explaining return contents, and it does so field by field. For a six-parameter polling read tool, the combination of return shape, lifecycle state, error behavior, filter composition, and credit cost leaves nothing an agent needs missing before calling it.

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 semantics: min_fit and top_n compose (top_n keeps the best N after the min_fit cut), omitting both means no cut, and an unscored creator survives only min_fit 0. It leaves page, per_page, and ref entirely 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 the specific resource (an Ultra Search and one page of its creator list) and enumerates the returned shape: stage, time-left estimate, counts, and per-creator tier/fit/reason/evidence/audience_type/near-miss/country signals/platform. That is far beyond a name restatement and clearly separates it from start_ultra_search, which only launches the search.

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?

It gives concrete operating guidance: omit search_id to read the newest search, wait and re-poll when results_ready is false, and expect the list to keep growing while crawl.running is true. It stops short of explicitly contrasting with sibling read tools such as get_creator or search_creators, so it falls one step shy of full when/when-not/alternatives coverage.

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

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