Influship Influencer Marketing MCP

autocomplete_creators

Read-only

Autocomplete creator names, usernames, or display names from partial input.

Use this for fast lookup when the user types a partial handle or name and you need to resolve it to canonical creator IDs (e.g., "find @cris" or "who's that fitness coach called Jane?"). Cheap and fast — prefer over search_creators for handle-style queries where the user already knows roughly who they want.

Use get_profile instead when the user gives an exact platform+username pair. Use search_creators for the same fuzzy creator lookup behavior with a less typeahead- specific name. Use semantic_search_creators only for discovery by topic, niche, audience, geography, or content style, not for resolving a known creator.

Examples:

User: "Who is that fitness coach called Jane?" -> use this tool.
User: "Find @cris..." -> use this tool to resolve the partial handle.
User: "Pull @niickjackson on Instagram" -> use get_profile, not this tool.

Returns a short list of matching creators with their IDs, platforms, and display names. Use the IDs returned here as input to get_creator, find_lookalike_creators, or match_creators for downstream operations.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`q`	Yes	Search query (min 2 characters)
`limit`	No	Maximum results to return
`scope`	No	Which platforms to include in results	all_platforms
`platform`	No	Filter by platform

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	No
`data`	No
`count`	No
`results`	No
`has_more`	No
`not_found`	No
`next_cursor`	No
`suggested_followups`	No

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, lowering the burden. The description adds useful behavioral context: it is 'cheap and fast', returns a short list of matching creators with IDs/platforms/display names, and suggests downstream usage. This goes beyond the annotations without contradicting them.

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

Conciseness5/5

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

The description is front-loaded with a clear purpose, followed by usage guidance and examples. Every sentence contributes: it explains when to use the tool, when not to, and what the output looks like. Despite its length, there is no redundancy or fluff.

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?

The description covers all essential context: purpose, usage boundaries, return values, and downstream integration. With an output schema present, the description need not detail return structures. The complexity of many sibling tools is well addressed by explicit comparisons.

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 input schema already fully documents all four parameters (q, limit, scope, platform). The description adds value by explaining the query context (partial handle/name) in examples, but does not elaborate on parameter semantics beyond the schema. This aligns with the baseline for full schema 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 clearly states that the tool autocompletes creator names, usernames, or display names from partial input. It uses specific verbs ('autocomplete', 'resolve') and names the resource, while also distinguishing itself from sibling tools like search_creators, get_profile, and semantic_search_creators.

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?

The description provides explicit guidance on when to use this tool versus alternatives: prefer it over search_creators for handle-style queries, use get_profile for exact platform+username, and use semantic_search_creators for broader discovery. Concrete examples illustrate the decision boundaries.

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

All Influship Influencer Marketing MCP tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0

Disambiguation2/5

Several tools have overlapping boundaries: autocomplete_creators and search_creators are described as near-equivalent fuzzy lookups, get_creator and get_profile both resolve exact platform+username input, and the Instagram/TikTok post helpers overlap with generic get_posts. The descriptions work hard to disambiguate, but an agent would frequently need to choose between two or three equally plausible tools.

Naming Consistency4/5

Most tools follow a clear verb_noun snake_case pattern, such as get_youtube_video, search_creators, match_creators, and render_creator_profile. Minor inconsistencies exist: singular/plural variants (get_instagram_post vs get_instagram_posts), list_ vs get_ for video listing, and search_creators carrying legacy semantic behavior under a lookup-sounding name.

Tool Count2/5

Twenty-eight tools places the server in the 'too many' range, and the count is inflated by near-duplicates like autocomplete_creators/search_creators, get_creator/get_profile, and singular/batch transcript variants. Even with three social platforms and rendering helpers, the surface would be more focused around 18–22 tools.

Completeness4/5

The core influencer research workflow is well covered: handle resolution, batch lookup, semantic discovery, lookalikes, posts, transcripts, YouTube search, matching, and comparison rendering. Gaps are minor—there is no creator shortlist persistence or cross-platform comment support—but the main discovery-to-match path has no dead ends.

Resources

Need Help?