Skip to main content
Glama
Sign In

Nava: UGC creators who are your customers

by com.meetnava
OverviewDiscussionsAdmin

Find creators who are the customer

find_creators

Starts a search for real TikTok creators who are the brand's customer, judged from their own bio and posts, active in the last 30 days, with typical views at least 0.3x followers. Only exact fits are returned, each with the quoted evidence for every must-have. Returns at once with a job_id and instant matches: creators Nava already checked that look like the brief. A fresh search graded against the exact must-haves follows, usually within 2 minutes: call get_job right away, it waits for the result. Free plan: 5 creators per email in all. Solo and Pro start once paid: find_creators returns a Stripe payment link. Use it when the brief is about who the creator is, not just a topic or follower count. Needs the user's email: if you don't have it, ask for it and their product's website in one short question, then call this right away. The full list with each creator's contact is emailed there.

Input Schema

NameRequiredDescriptionDefault
whoYesWho the creators should be, in plain words: "ER nurses who work nights", "account executives at SaaS companies", "parents of kids with food allergies".
mustNoRequirements every match must show, e.g. ["works nights"]. Default: everything in `who`.
niceNoPreferences that rank a creator higher but aren't required, e.g. ["B2B software"]. Moving a requirement here can multiply the matches.
planNofree (default): 5 creators per email in all. solo ($27/month) and pro ($97/month): find_creators returns a Stripe payment link and the search starts once it's paid. Only pick a paid plan when the user asked for it.
brandNoThe brand or product name.
notesNo
countryNoOnly if the user named a country. A preference: creators there rank first, but it isn't required. To require it, add it to must (e.g. "lives in the US").
followersNoFollower range. Default 1,000 to 150,000.
platformsNoOnly "tiktok" for now.
max_matchesNoAt most this many exact fits. Capped by the plan.
product_urlNoThe product's website, if the user has one. Ask for it with the email.
contact_emailYesThe user's email. Nava emails the full list with each creator's contact there, and replies reach Nava's founder.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / contact_email / description
      Previous value: -"Where Nava sends the results and can reach the person this is for."New value: +"The user's email. Nava emails the full list with each creator's contact there, and replies reach Nava's founder."
    • addedInput schema / properties / country / description
      Added value: +"Only if the user named a country. A preference: creators there rank first, but it isn't required. To require it, add it to must (e.g. \"lives in the US\")."
    • addedInput schema / properties / product_url / description
      Added value: +"The product's website, if the user has one. Ask for it with the email."
  2. Changed1 schema field changed
    • changedInput schema / properties / plan / description
      Previous value: -"free (default): 5 creators per email in all. solo ($27/month) and pro ($97/month): Nava emails a payment link and the search starts once it's paid. Only pick a paid plan when the user asked for it."New value: +"free (default): 5 creators per email in all. solo ($27/month) and pro ($97/month): find_creators returns a Stripe payment link and the search starts once it's paid. Only pick a paid plan when the user asked for it."
  3. Changed1 schema field changed
    • changedInput schema / properties / plan / description
      Previous value: -"free (default): top 5. solo and pro come with a payment link; nothing is charged before the creators arrive."New value: +"free (default): 5 creators per email in all. solo ($27/month) and pro ($97/month): Nava emails a payment link and the search starts once it's paid. Only pick a paid plan when the user asked for it."
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false and openWorldHint=false; the description adds substantial behavior the agent could not otherwise know: an async job pattern returning a job_id plus instant partial matches, a graded fresh pass within ~2 minutes, the get_job wait semantics, free-plan quota of 5 creators per email, and that paid plans return a Stripe payment link before search starts. It also discloses that the full contact list is emailed, which is a real side effect not captured by 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?

Front-loaded with the capability and criteria, and the async/plan details follow in a logical order. It is dense but the email-collection and payment-link passages repeat context already implied in the schema, so it is slightly longer than it needs to be.

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 a 12-parameter, async, plan-gated tool with no output schema, the description covers initiation, return shape (job_id + instant matches), the required follow-up call, quota limits, and payment gating. An agent has enough to invoke it correctly and to handle the post-call flow.

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 92%, so most parameters are already documented; the description still adds value by explaining the consequence of must vs nice ('Only exact fits are returned, each with the quoted evidence for every must-have') and by instructing the agent to collect contact_email and product_url together. Marginal but genuine enrichment beyond the schema text.

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?

Opens with a specific verb and resource: 'Starts a search for real TikTok creators who are the brand's customer,' then narrows with concrete criteria (bio/posts evidence, active last 30 days, 0.3x followers view floor). It also names the follow-up sibling get_job, so an agent can distinguish this initiation tool from the job-polling tool 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?

Explicit routing rule: 'Use it when the brief is about who the creator is, not just a topic or follower count.' It also states prerequisites (needs the user's email; ask for email and product website in one short question) and the immediate next action ('call get_job right away'), leaving nothing to inference.

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

All Nava: UGC creators who are your customers 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